Rowhammer를 한 문장으로 말하면, 어떤 DRAM row를 반복적으로 열고 닫는 과정이 주변 row의 전하를 흔들어, 직접 쓰지 않은 bit를 뒤집을 수 있는 현상이다. 반도체 엔지니어 입장에서는 이것이 가장 불편한 종류의 문제다. 회로는 spec대로 동작하는 것처럼 보이지만, 특정 access pattern 아래에서는 memory integrity가 깨진다.
이 글은 exploit tutorial이 아니다. 공격 코드를 만들거나 재현하는 절차는 다루지 않는다. 대신 DRAM 물리, memory controller, ECC/RAS, validation 관점에서 Rowhammer가 왜 아직 끝난 문제가 아닌지 설명한다.
1. Rowhammer는 왜 생기나
DRAM cell은 capacitor에 전하를 저장한다. 시간이 지나면 전하는 샌다. 그래서 DRAM은 refresh가 필요하다. 문제는 scaling이다. cell이 작아지고 row pitch가 줄어들수록, 한 row를 강하게 반복 activation할 때 주변 row가 받는 전기적 stress가 커진다.
Rowhammer의 핵심은 “victim row를 직접 접근하지 않아도 victim row의 bit가 바뀔 수 있다”는 점이다. CPU, OS, hypervisor는 page table과 privilege boundary를 기준으로 protection을 설계한다. 하지만 Rowhammer는 그 아래 DRAM array level에서 protection assumption을 깨버린다.
2014년 ISCA 논문은 commodity DRAM module에서 이 현상이 넓게 존재한다는 것을 실험적으로 보였다. 당시만 해도 reliability 문제처럼 보였지만, 곧 security 문제가 되었다. 2015년 Google Project Zero는 unprivileged user process에서 kernel privilege escalation이 가능하다는 것을 공개했다.
2. 왜 보안 문제가 되는가
메모리 bit flip 자체는 오래된 reliability 문제다. 차이는 control이다. random soft error는 ECC와 retry로 다룰 수 있다. Rowhammer는 공격자가 memory access pattern을 조작해 특정 공간에서 bit flip을 유도하려고 시도할 수 있다는 점이 다르다.
대표적인 target은 page table entry, permission bit, cryptographic key material, sandbox boundary 같은 구조다. 실제 공격은 매우 복잡하고 환경 의존적이지만, 반도체 엔지니어에게 중요한 메시지는 단순하다. “전기적 disturbance가 architectural security boundary를 건드릴 수 있다.”
이것은 Spectre/Meltdown과 닮은 면이 있다. 둘 다 software가 믿었던 abstraction 아래의 hardware behavior가 security problem이 된 사례다. 다만 Rowhammer는 transient execution이 아니라 memory array physics에서 출발한다.
3. TRR은 왜 충분하지 않았나
DDR4 시대의 대표 방어는 Target Row Refresh, 흔히 TRR이라고 부르는 계열이다. idea는 간단하다. 많이 열리는 aggressor row를 감지하고, 주변 victim row를 추가 refresh한다. 말만 들으면 정답처럼 보인다.
문제는 구현이다. TRR은 표준 하나로 투명하게 정의된 단일 알고리즘이라기보다, vendor와 controller마다 다른 비공개 mitigation 묶음에 가깝다. TRRespass 연구는 이 불투명성이 왜 위험한지 보여줬다. 단순 single-sided, double-sided pattern이 막혀도, 더 많은 aggressor row를 쓰는 many-sided pattern이 mitigation tracker를 압박할 수 있다.
Blacksmith는 여기서 한 단계 더 나아갔다. 균일한 hammering이 아니라 frequency, phase, amplitude를 바꾼 비균일 pattern을 탐색해 DDR4 TRR을 우회하는 방향을 보였다. 반도체 엔지니어 관점에서 핵심은 “defense가 pattern-specific이면 fuzzer가 결국 빈틈을 찾는다”는 점이다.
4. Half-Double과 RowPress: 인접 row만의 문제가 아니다
초기 Rowhammer 설명은 보통 aggressor row 바로 옆 victim row를 생각한다. 하지만 Half-Double은 distance-2 row까지 disturbance가 전파될 수 있음을 보였다. 즉, row adjacency model이 단순하지 않다.
RowPress는 또 다른 방향이다. Rowhammer가 “많이 열고 닫기”라면, RowPress는 row를 오래 열어두는 시간, 즉 aggressor row on time이 문제를 키울 수 있다는 것을 보여준다. 이것은 controller scheduling과 page policy가 security와 연결된다는 뜻이다.
여기서 중요한 engineering point는 refresh만 늘리는 것으로 모든 문제가 해결되지 않는다는 점이다. activation count, open-row time, bank scheduling, address mapping, thermal condition이 모두 disturbance risk에 영향을 준다.
5. ECC와 on-die ECC는 만능인가
ECC는 Rowhammer를 어렵게 만든다. 하지만 “ECC가 있으니 안전하다”는 말은 과하다. ECC는 error를 detect/correct하는 layer이지, 공격자가 disturbance를 만들 수 없게 하는 root-cause mitigation은 아니다.
Server DRAM에서는 ECC event logging, patrol scrub, page retirement가 중요해진다. Error가 correction 가능한 순간에 끝내는 것이 아니라, 반복되는 corrected error가 vulnerable physical page를 가리키는지 운영체제와 firmware가 판단해야 한다.
DDR5의 on-die ECC도 마찬가지다. on-die ECC는 DRAM chip 내부 yield와 reliability를 돕지만, system-level security guarantee와 동일하지 않다. 최근 DDR5 Rowhammer 연구들이 계속 나오는 이유가 여기에 있다.
6. 검증 관점: “safe DIMM”이라는 말의 위험
Rowhammer validation은 단순 pass/fail이 아니다. 어떤 CPU memory controller인가, BIOS 설정은 무엇인가, refresh policy는 어떤가, temperature는 어떤가, DIMM vendor와 revision은 무엇인가, workload가 어떤 access pattern을 만들 수 있는가에 따라 결과가 달라진다.
따라서 반도체 엔지니어가 물어야 할 질문은 “이 DRAM은 Rowhammer-safe인가?”가 아니다. 더 정확한 질문은 다음이다.
- 어떤 aggressor tracking threshold와 refresh policy를 가정했나?
- TRR-like mitigation이 transparent하게 검증 가능한가?
- ECC event를 system software가 어떻게 consume하고 page retirement로 연결하는가?
- VM, container, browser, GPU, accelerator 같은 shared environment에서 threat model이 달라지는가?
- temperature, voltage, aging, workload mix가 disturbance margin을 얼마나 줄이는가?
7. GPU와 accelerator 메모리로 확장되는 문제
Rowhammer를 CPU-side DDR 문제로만 보면 시야가 좁다. AI accelerator와 GPU는 대용량 GDDR/HBM을 공유하고, cloud에서는 여러 tenant나 여러 workload가 같은 accelerator fabric을 쓴다. memory protection과 address translation이 복잡해질수록, bit flip 하나가 model weight, page mapping, buffer boundary에 미치는 영향도 달라진다.
특히 AI workload에서는 “정확도 조금 떨어짐”이 아니라, 특정 model parameter나 metadata corruption이 system behavior를 바꿀 수 있다. GPU memory Rowhammer 연구가 중요해지는 이유다. HBM/GDDR의 high bandwidth는 장점이지만, 동시에 공격자가 memory array에 높은 traffic pressure를 줄 수 있는 구조이기도 하다.
8. 한국 메모리 산업 관점
한국은 DRAM의 핵심 공급망이다. 삼성전자와 SK hynix가 HBM, DDR5, LPDDR, GDDR의 중심에 있기 때문에 Rowhammer는 남의 문제가 아니다. 단순히 “보안 취약점 대응”이 아니라 제품 신뢰성, cloud qualification, hyperscaler acceptance, RAS feature 경쟁력과 직결된다.
HBM4, custom HBM base die, CXL memory, AI server memory expansion이 커질수록 memory vendor는 더 많은 system-level 책임을 받는다. DRAM die만 잘 만드는 것이 아니라, controller 협업, firmware policy, ECC reporting, package thermal model, validation collateral까지 묶어서 제공해야 한다.
국내 반도체 엔지니어에게도 시사점이 있다. memory 설계자는 cell과 sense amplifier만 보면 안 된다. system architect는 page policy와 scheduling을 알아야 한다. security engineer는 physical fault model을 이해해야 한다. EDA/validation engineer는 “정상 동작 조건”과 “악의적 access pattern” 사이의 gap을 시험해야 한다.
9. 엔지니어 체크리스트
- DRAM designer: cell leakage, coupling, restore margin, wordline disturbance, temperature/aging corner를 threat model로 연결해야 한다.
- Memory controller designer: activation counter, refresh budget, row address mapping, bank scheduling이 security surface가 된다.
- Firmware/RAS engineer: corrected error를 단순 로그가 아니라 page retirement decision으로 이어야 한다.
- System architect: ECC, IOMMU, VM isolation, accelerator memory sharing을 end-to-end로 봐야 한다.
- Validation engineer: vendor claim보다 pattern diversity, temperature, voltage, workload mix, aging margin을 봐야 한다.
10. 결론
Rowhammer는 “해커가 DRAM을 때린다”는 흥미로운 보안 이야기로 끝나지 않는다. 반도체 엔지니어에게 Rowhammer는 scaling의 비용이다. cell이 작아지고 density가 올라가면, physical isolation margin은 줄어든다. 그 margin을 architecture, controller, ECC, OS가 나눠서 메워야 한다.
그래서 Rowhammer의 교훈은 명확하다. memory integrity는 DRAM vendor 혼자 해결하는 문제가 아니다. DRAM array, memory controller, firmware, OS, hypervisor, cloud scheduler, accelerator runtime이 하나의 방어 체인을 만든다. 그 체인의 어느 한 곳이 opaque하거나 pattern-specific이면, 다음 연구가 그 빈틈을 찾는다.
AI 시대의 memory는 더 빠르고, 더 크고, 더 가까워지고 있다. HBM, GDDR, DDR5, CXL memory가 모두 system 안으로 깊이 들어온다. Rowhammer는 이 흐름에서 계속 봐야 할 warning sign이다. 메모리는 단순 storage가 아니라 security boundary다.
원문 링크
- Kim et al., Flipping Bits in Memory Without Accessing Them, ISCA 2014
- Google Project Zero, Exploiting the DRAM rowhammer bug, 2015
- Google Security Blog, Half-Double, 2021
- Half-Double, USENIX Security 2022
- VUSec, TRRespass
- ETH COMSEC, Blacksmith
- RowPress vulnerability overview
- Google Security Blog, supporting Rowhammer research
- ETH COMSEC, Phoenix DDR5 Rowhammer
