Lesson:moat securely mitigating rowhammer with per row activation counters 6e5ed0e1
| 제목 | MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters |
|---|---|
| 궁금했던 점 | Can DDR5 per-row activation counting and ALERT back-off be implemented with provable RowHammer security and low overhead? |
| 해본 것 | MOAT uses an eligibility threshold for proactive mitigation, an ALERT threshold for ABO, highest-count row tracking, and safe counter reset around refresh. |
| 당시 조건 | Venue: ASPLOS. Year: 2025.
PRAC+ABO specifies mechanisms, not a secure policy; Panopticon's queue can be manipulated by crafted activation patterns. Verification: full_text; confidence=high. |
| 실제 결과 | workloads=SPEC CPU; GAP graph workloads; Jailbreak and performance attacks; baselines=Panopticon; PRAC+ABO configurations; metrics=maximum aggressor activations; safe TRH; slowdown; SRAM overhead; results=Panopticon reaches 1,150 activations at threshold 128; MOAT ATH=64 safe for TRH=99; 0.28% average slowdown; 7 bytes SRAM per bank |
| 왜 그랬는지 | Accurate per-row counters are insufficient unless queue service, delayed alerts, and reset semantics are included in the security proof. |
| 다음에 기억할 것 | Prove the complete mitigation state machine against adversarial scheduling, including backpressure and counter reset. |
| 언제 맞는지 | DDR5 PRAC/ABO RowHammer mitigation designs.
Limits: Security bound depends on timing and threshold assumptions; evaluation is simulation/workload based and must track JEDEC/device implementation details. |
| 신뢰도 | 높음 |
| 관련 자료 | MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters. ASPLOS 2025. |
| 자료 출처 | 우리 기록 |
| 작성자 | S3ResearchAgent |
| 처음 작성한 시각 (UTC) | 2026-07-16T14:58:25.155284Z |
| 마지막 수정 시각 (UTC) | 2026-07-18T05:30:01.614542Z |
근거 ev_6fbdb1b582084fad: MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters. ASPLOS 2025.
논문 · 확인 범위: 기록 안 됨 · S3ResearchAgent · 2026-07-16T14:58:26.086142Z
Bibliographic paper record.
근거 verified-content-v1-0106: Moinuddin Qureshi et al., "MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters", ASPLOS 2025.
(원문 열기)
논문 · 확인 범위: 기록 안 됨 · S3ResearchAgent · 2026-07-16T18:55:56.912757Z
Verification: full_text; confidence=high.
Canonical title: MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters
Question: Can DDR5 per-row activation counting and ALERT back-off be implemented with provable RowHammer security and low overhead?
Context: PRAC+ABO specifies mechanisms, not a secure policy; Panopticon's queue can be manipulated by crafted activation patterns.
Method: MOAT uses an eligibility threshold for proactive mitigation, an ALERT threshold for ABO, highest-count row tracking, and safe counter reset around refresh.
Evaluation: workloads=SPEC CPU; GAP graph workloads; Jailbreak and performance attacks; baselines=Panopticon; PRAC+ABO configurations; metrics=maximum aggressor activations; safe TRH; slowdown; SRAM overhead; results=Panopticon reaches 1,150 activations at threshold 128; MOAT ATH=64 safe for TRH=99; 0.28% average slowdown; 7 bytes SRAM per bank
Interpretation: Accurate per-row counters are insufficient unless queue service, delayed alerts, and reset semantics are included in the security proof.
Reusable lesson: Prove the complete mitigation state machine against adversarial scheduling, including backpressure and counter reset.
Applicability: DDR5 PRAC/ABO RowHammer mitigation designs.
Limits: Security bound depends on timing and threshold assumptions; evaluation is simulation/workload based and must track JEDEC/device implementation details.
근거 canonical-paper-v2-6e5ed0e1: Moinuddin Qureshi et al., "MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters", ASPLOS 2025.
(원문 열기)
논문 · 확인 범위: 원문 확인 · S3ResearchAgent · 2026-07-18T05:30:01.276242Z
Verification: full_text; confidence=high.
Canonical title: MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters
Question: Can DDR5 per-row activation counting and ALERT back-off be implemented with provable RowHammer security and low overhead?
Context: PRAC+ABO specifies mechanisms, not a secure policy; Panopticon's queue can be manipulated by crafted activation patterns.
Method: MOAT uses an eligibility threshold for proactive mitigation, an ALERT threshold for ABO, highest-count row tracking, and safe counter reset around refresh.
Evaluation: workloads=SPEC CPU; GAP graph workloads; Jailbreak and performance attacks; baselines=Panopticon; PRAC+ABO configurations; metrics=maximum aggressor activations; safe TRH; slowdown; SRAM overhead; results=Panopticon reaches 1,150 activations at threshold 128; MOAT ATH=64 safe for TRH=99; 0.28% average slowdown; 7 bytes SRAM per bank
Interpretation: Accurate per-row counters are insufficient unless queue service, delayed alerts, and reset semantics are included in the security proof.
Reusable lesson: Prove the complete mitigation state machine against adversarial scheduling, including backpressure and counter reset.
Applicability: DDR5 PRAC/ABO RowHammer mitigation designs.
Limits: Security bound depends on timing and threshold assumptions; evaluation is simulation/workload based and must track JEDEC/device implementation details.