GPUHammer: GDDR6 메모리에서의 Rowhammer 재현 연구
GPUHammer: GPU 메모리도 안전하지 않다
들어가며..
메모리 제품 관련 취약점들을 살펴보다 보면 그중 가장 악명 높은 주제 중 하나는 바로 Rowhammer라고 생각합니다.
RowHammer는 DRAM 셀을 특정 패턴으로 매우 빠르게 열고 닫으면, 인접한 셀의 전하가 새어나가
비트 플립(Bit flip)이 일어나는 현상입니다.
2014년 CPU DRAM에서 처음 보고된 이후 최근 발표된 DDR5에서 RowHammer를 성공한 Phoenix 등을 비롯하여
수많은 변종 공격이 등장했지만,
GPU는 구조가 다르기 때문에 상대적으로 안전하다고 여겨졌습니다.
그러나 이번 IEEE S&P 2025에서 발표된 GPUHammer는
그 믿음을 정면으로 뒤흔든 연구였습니다.
사실 저도 업무 특성상 Hardware 공격 관련 논문만 읽어보고 실제로 Hardware 공격을 해본 경험은 없습니다.
그래서 혹시나 틀린 부분이 있다면 메일로 알려주시면 감사하겠으며, 이제부터 GPUHammer에 대해서 간략하게 설명하도록 해보겠습니다.
Rowhammer란?
GPUHammer를 보기 전에 앞서 RowHammer를 먼저 간략하게 살펴보고 가겠습니다.
DRAM은 전하를 저장하는 작은 셀(cell)로 구성되어 있으며, 일정 주기마다 리프레시(refresh)를 해줘야 합니다.
그런데 공격자가 동일한 메모리 행(row)을 수천 번 이상 빠르게 열고 닫으면,
옆에 있는 행의 전하가 간섭되어 데이터가 뒤집히는 현상이 발생합니다.
이게 바로 Rowhammer입니다. 원래는 물리적 결함처럼 보였지만,
연구자들은 이를 이용해 커널 권한을 얻거나, 페이지 테이블을 조작하는 공격까지 시연했습니다.
GPUHammer는 이 원리를 GPU 메모리(GDDR6) 환경에 맞게 재현한 최초의 연구입니다.
GPUHammer 연구 개요
GPU에서 Rowhammer가 어려운 이유
GPU 메모리는 CPU와 달리 GDDR6 / GDDR6X / HBM2e와 같은 고속 메모리를 사용합니다. 이들은 리프레시 주기가 짧고 속도도 빠르며, 내부 구조도 공개되어 있지 않습니다.
- GPU는 가상주소만 공개하고, 실제 물리주소 ↔ 뱅크/로우 매핑은 숨겨져 있음
- GPU 스케줄러(워프 단위)가 병렬 접근을 제어하기 때문에 행을 빠르게 두드리기 어려움
- 수백 개 스레드가 동시에 동작해 리프레시 타이밍을 예측하기 어려움
GPUHammer의 핵심 기법
연구팀은 이러한 한계를 극복하기 위해 세 가지 핵심 전략을 사용했습니다.
- Latency 측정으로 뱅크/로우 매핑 추정
두 주소를 번갈아 접근했을 때 지연 시간이 길면 같은 뱅크의 다른 로우로 매핑된다는 점을 이용했습니다. - 워프 단위 최적화
워프 수를 8 이하로 줄이고 각 스레드가 다른 로우를 번갈아 hammering 하도록 조정했습니다. - 리프레시 주기 맞추기
명령 사이에 add 연산만 수행해 “빈 시간(bubble)”을 만들고, GPU 리프레시와 hammering 패턴이 맞물리도록 타이밍을 조절했습니다.
GPUHammer는 “어디를 두드릴지(뱅크/로우 추정) → 얼마나 빠르게 두드릴지(활성화율 확보) → 언제 두드릴지(리프레시와 동기화)”라는 세 가지 난제를 순차적으로 해결하여 GPU 환경에서 Rowhammer를 실현한 연구입니다. 아래에 각 단계의 아이디어와 구현적 고려사항 몇가지를 뽑아 정리해보았습니다.
행동 기반 주소 역추정 — latency profiling
GPU는 물리 주소나 뱅크·로우 매핑 정보를 노출하지 않기 때문에, 연구팀은 직접 “측정”으로 이를 역추정했습니다. 핵심 관찰은 row-buffer conflict(로우 버퍼 충돌)입니다. 같은 뱅크의 서로 다른 로우를 번갈아 접근하면 DRAM 내부의 로우 버퍼가 자주 교체되어 메모리 접근 지연(latency)이 커집니다.
실무적으로는 큰 버퍼를 여러 간격(stride)으로 샘플링해 후보 주소 집합을 만들고, 주소쌍을 번갈아 접근하면서 평균 응답시간을 측정합니다. 특정 쌍에서 지연이 일관되게 커지면 그 쌍은 ‘같은 뱅크·다른 로우’로 분류됩니다. 이렇게 충돌이 자주 발생하는 주소들을 모아 클러스터링하면 장치별로 의미 있는 “뱅크 그룹”을 찾아낼 수 있습니다.
주의점: 측정 시 캐시나 프리패치에 의한 왜곡을 피해야 합니다. 따라서 후보를 충분히 넓게 잡고, 캐시·L2 영향과 연관된 변수를 통제하면서 반복 측정을 통해 통계적으로 유의한 충돌 쌍만 추려야 합니다.
활성화율 확보(activation rate) — 워프·스레드·캐시 조율
Rowhammer는 짧은 시간에 동일 뱅크의 서로 다른 로우를 수천 번 이상 열어야 합니다. 이를 활성화율이라고 합니다. GPU에서는 워프(warp)라는 단위 스케줄링이 존재하고 수많은 워크스레드가 병렬로 돌아가기 때문에, 단순히 스레드를 많이 늘리는 방식은 오히려 스케줄링 간섭을 불러와 목표 행에 집중된 높은 활성화율을 얻기 어렵습니다.
GPUHammer는 다음과 같은 조율 전략을 사용했습니다.
- 워프 수의 제한: 전체 워프 수(동시 활성 워프)를 적절히 제한해 스케줄러 간섭을 줄이고, 동일 워프 내에서 연속적이고 빠른 접근이 유지되도록 설계했습니다. 즉, ‘많이 돌리는 것’보다 ‘집중해서 돌리는 것’이 유리합니다.
- 워프 내부 역할 분담: 하나의 워프 내부에서 각 스레드가 서로 다른 물리적 오프셋(로우 후보)을 담당하도록 하여 워프 단위로 빠른 AB 교대 접근을 수행하게 했습니다. 이렇게 하면 워프 내부 병렬성을 이용하면서도 실제 DRAM 활성화가 많이 일어나도록 만들 수 있습니다.
- 캐시 우회/플러시 전략: 캐시에 잔류하면 DRAM 트래픽이 줄어 활성화 효과가 약화됩니다. 때문에 주기적인 캐시 비우기(또는 캐시 힌트를 이용한 강제 DRAM 접근), 큰 작업 집합과 불연속 접근(stride)을 사용해 실제 DRAM 접근을 유도합니다.
리프레시(tREFI)와 해머링 패턴의 동기화
DRAM은 주기적으로 셀을 리프레시해서 전하를 보충합니다. 만약 리프레시가 해머링 도중 끼어들면 플립이 일어나지 않으므로, 공격자는 해머링 패턴과 리프레시 타이밍을 정밀하게 맞출 필요가 있습니다.
GPUHammer는 전역 동기화(예: 워프 간 강제 동기화) 대신, 워프 내부에서만 짧은 지연을 주는 방식을 도입했습니다. 워프 내부에서 계산만 하는 작은 지연 구간을 만들어 메모리 컨트롤러 관점에서 ‘빈 슬롯(bubble)’을 만들고, 이 틈이 정해진 주기로 반복되도록 하여 리프레시가 일정한 타이밍으로 들어가게 유도합니다. 결과적으로 해머링의 교대 순서와 리프레시의 삽입 주기가 안정적으로 엮이면서 비트플립 발생 조건을 만족시키기 쉬워집니다.
n-sided 패턴 탐색(물리적 배치의 비연속성 대응)
여기서 말하는 n-sided는 공격에 참여하는 서로 다른 공격자(aggressor) 행의 수 또는 victim 주변에서 몇 칸까지 포함하느냐를 일반화한 용어입니다. 예를 들어 single-sided는 한쪽만, double-sided는 양쪽 한 칸씩을 두드리는 패턴이고, n-sided는 이보다 더 많은 주변 행(±1, ±2, ±3 …)을 포함합니다.
GPUHammer에서는 단순히 ‘항상 double-sided가 최강’이라는 통념이 깨졌습니다. 특정 장치(A6000)에서는 논리적 인접(예: ±1)이 아니라 물리적으로 인접한 셀 구조 때문에 ±2 오프셋이 더 취약하게 관찰되었고, 그 결과 victim의 ±2만 single-sided로 두드려도 비트플립이 발생했습니다. 이것은 논리 주소와 실제 물리적 로우 배치가 일대일로 대응하지 않을 수 있음을 보여줍니다.
따라서 연구팀은 다양한 n-값(여러 오프셋 조합)을 자동으로 탐색하여, 장치별로 실제로 효과적인 해머 패턴—즉 '어떤 오프셋 조합이 실제 플립을 잘 유발하는가'—를 찾아내고 이를 기반으로 공격 효율을 최적화했습니다.
에러 검출·메모리 배치 유도(memory massaging)
공격의 목표가 단순한 비트플립 발견이 아니라 민감 데이터(모델 weight, 페이지 테이블, 키 등)에 영향을 줘서 실질적 피해를 만드는 것이므로, 두 단계가 필요합니다.
- 정밀 검출: hammer 수행 전후로 대상 메모리 영역을 정밀 스캔해 바이트·비트 단위의 변화를 확인합니다. 노이즈/측정 오류를 걸러내기 위해 여러 번 반복 측정하고, 통계적으로 일관된 플립만 의미 있는 결과로 간주합니다.
- 메모리 배치 유도(memory massaging): 공격자는 메모리 할당·해제를 반복해 목표 데이터가 취약한 물리 위치로 재배치되도록 유도합니다. 연구에서는 GPU 드라이버의 빠른 재활용 정책을 이용해 모델 weight를 취약 셀에 올리는 과정을 시연했습니다. 따라서 드라이버의 재활용 정책이 예측 가능할수록 공격 성공률은 올라갑니다.
구현상의 고려사항 및 실험적 튜닝
GPU 환경은 복잡하고 제조사·모델마다 차이가 큽니다. 따라서 실험/공격을 현실적으로 수행하려면 다음과 같은 실험적 튜닝이 필요합니다.
- 캐시·프리패처 영향 최소화: 후보 집합의 stride, 접근 패턴 크기, 주기적 캐시 비우기 등을 실험적으로 조정.
- 워프/스레드 파라미터 조정: 너무 많은 워프는 오히려 경쟁을 일으켜 불리하므로 ‘적정 워프 수(sweet spot)’를 찾아야 함.
- 타이밍(리프레시) 적합성 검증: 리프레시 간격·빈 슬롯 생성 주기를 작게 변화시키며 플립 발생 민감도를 측정.
- 장치별 패턴 저장: 초기 탐색에서 유효 패턴을 찾아 데이터베이스화하면 후속 공격이 빨라짐.
주요 결과와 발견
NVIDIA RTX A6000 (GDDR6)을 대상으로 실험한 결과:
- 모든 뱅크에서 실제 비트플립이 관찰됨
- A100 (HBM2e)과 RTX3080 (GDDR6X)에서는 플립 없음
- Rowhammer Threshold(TRH)는 약 12,300번으로 CPU DDR4와 유사
- TRR(Target Row Refresh)은 16개 행까지만 추적 가능 — n≥17일 때 플립 발생
- FP16 weight의 exponent 비트 하나만 뒤집혀도 모델 정확도 80% → 0.02%
보호 기법과 한계
GPUHammer는 기존 방어책들의 한계를 명확히 보여주었습니다.
- TRR (Target Row Refresh): 일정 횟수 이상 접근 시 주변 행을 자동으로 refresh 하지만, 추적 가능한 행 수가 제한됨.
- ECC (Error Correcting Code): 단일 비트플립 정도는 수정하지만, 연속적 비트플립이나 다중 셀 영향에는 취약.
- Memory Massaging: 공격자가 GPU 메모리 할당을 조작해 취약한 위치에 모델 weight를 유도할 수 있음.
- ECC 활성화 및 물리주소 무작위화(Address Randomization)
- 메모리 재사용 정책의 불확실성 증가 (Massaging 방해)
- 향후 DRAM에서 더 정교한 TRR/ODECC 설계 필요
마무리
GPUHammer는 GPU 특유의 병렬·스케줄링 구조를 역이용해 Rowhammer를 실현했으며, 그만큼 장치별·드라이버별 취약성이 실무적으로 존재함을 보여주었습니다.
방어팀은 단일 기법(예: TRR 나 ECC)만 믿지 말고 메모리 재활용 정책, 드라이버 동작, 하드웨어 레벨의 방어 설계까지 함께 검토해야 할 것입니다.
특히, 오늘날 GPU는 단순 그래픽 가속기가 아니라 AI 학습과 데이터센터 인프라의 핵심입니다.
하지만 GPU 메모리 역시 Rowhammer로부터 자유롭지 않다는 사실은 큰 경고입니다.
단 한 비트의 플립이 AI 모델의 정확도를 완전히 붕괴시킬 수 있으며,
ECC나 TRR만으로는 이를 완벽히 막을 수 없습니다.
따라서 AI/ML 환경에서도 하드웨어 신뢰성 테스트, Rowhammer 내성 검증이 필수적일 것 같습니다.
해당 GPUHammer 연구는 “GPU는 안전하다”는 기존 인식을 깨뜨렸습니다.
GDDR6 기반 GPU에서도 Rowhammer로 인한 비트플립이 실제로 발생할 수 있음을 보여주었고,
이는 GPU 보안이 더 이상 선택이 아닌 필수 영역임을 뜻합니다.
특히 AI 모델의 무결성을 보장하기 위해선 하드웨어-소프트웨어 전 계층의 공동 대응이 필요해보이며,
앞으로 HBM3 등 차세대 메모리에서도 유사한 공격을 완전히 막을 수 있을지는 여전히 미지수로 남아있는 것 같습니다.
※ 혹시 잘못된 내용이나 추가할 부분이 있다면 메일로 알려주시면 감사하겠습니다!