Rowhammer 방어는 정확한 추적을 위해 메모리 컨트롤러에 큰 연관 검색 표를 넣거나, 공격이 없어도 DRAM 대역폭을 쓰는 확률적 샘플링을 선택해야 했습니다. Microsoft가 Azure Cobalt 200에 구현한 Sigries는 두 방식을 결합하고 서브뱅크 단위로 모드를 바꿉니다[1].
운영에서 확인할 문제는 최악 조건의 보호 수준을 유지하면서도 모든 메모리 접근에 그 비용을 부과하지 않을 수 있느냐입니다. 이 글은 Sigries가 국소적인 접근 압력을 감지하고 추적 모드를 바꾸며 오버헤드를 제한하는 과정을 설명하고, Azure 구현에서 확인된 결과와 DRAM별 임계값에 따라 달라지는 보호 조건을 구분합니다.
작은 표가 전환 조건을 판단하는 기준
경량 모드에서는 서브뱅크마다 수십 개 이하의 항목을 가진 Misra-Gries 카운터를 사용합니다. 정상 접근과 일부 공격은 이 표에서 처리됩니다. 넘침 동작이 추적 한계를 나타내면 해당 서브뱅크만 행 샘플링을 쓰는 강화 모드(heavy mode)로 바뀝니다. 다른 서브뱅크는 계속 카운팅하므로 공격 비용이 전체 메모리로 퍼지지 않습니다.
추적 기반 평가에서 모든 일반 작업은 경량 모드에 머물렀고 추가 DRAM 대역폭을 쓰지 않았습니다. 표가 작아 면적과 전력 비용도 낮습니다. 반대로 카운터를 넘치는 공격에서는 샘플링 비용을 감수해 방어 보장을 유지합니다.
Rowhammer는 접근 이력을 보안 경계로 만드는 방식
DRAM 행을 반복 활성화하면 피해 행에 직접 쓰지 않고도 이웃 셀의 비트가 바뀔 수 있습니다. 임계치는 장치 세대, 온도, 리프레시, 접근 패턴에 따라 달라집니다. 메모리 컨트롤러는 위험한 누적 전에 예방 리프레시를 실행할 만큼 최근 접근을 추적해야 합니다[1].
모든 행을 정확히 세려면 큰 고속 상태가 필요하고 일부 접근만 표본화하면 SRAM은 줄지만 메모리 트래픽과 확률적 탐지가 생깁니다. 클라우드 SoC는 공격이 없는 시간에도 많은 DIMM을 계속 보호하면서 테넌트에게 약속한 대역폭을 지켜야 합니다. 컨트롤러 기준은 시험한 DRAM 임계치보다 충분히 낮고 구현 지연까지 포함해야 합니다.
서브뱅크 단위가 상태와 확장을 제한하는 조건
Sigries는 전역 표 하나가 아니라 DRAM 서브뱅크별로 추적합니다. 한 영역의 정상 트래픽이 다른 영역의 계수기를 채우지 않고, 공격이 집중된 서브뱅크만 중량 보호 방식으로 전환합니다. 정상 비용과 공격 비용을 공간적으로 제한합니다.
이 범위는 실제 주소 매핑과 맞아야 합니다. 채널, 랭크, 뱅크, 서브뱅크, 행, 인터리빙 구조가 어떤 활성화가 피해 행에 영향을 주는지 정합니다. 펌웨어나 메모리 구성이 매핑을 바꾸면 방어 매개변수도 함께 바뀌어야 합니다.
한 서브뱅크의 공격도 공유 명령·데이터 자원을 쓸 수 있습니다. 강화 모드의 비용 상한은 해당 영역의 추가 리프레시뿐 아니라 다른 테넌트의 지연까지 포함해 측정해야 합니다.
Misra-Gries는 정확한 계수기 대신 전환 조건을 제공하는 기능
Misra-Gries는 자주 나타나는 후보 행과 근사 계수값을 작은 표에 유지합니다. 새 항목을 넣을 수 없을 때 계수기를 줄이거나 넘침 상태를 남기며, 충분히 자주 나타난 항목이 계속 추적에서 빠질 수 없다는 성질을 제공합니다. Sigries는 이 성질로 경량 모드를 계속 사용해도 안전한지 결정합니다.
작은 표는 의도적입니다. 정상 지역성과 단순 공격은 수십 항목에 들어가지만 많은 행으로 활성화를 퍼뜨리는 패턴은 표를 압박합니다. 이 신호가 나타나면 불충분한 계수기를 계속 믿지 않고 해당 서브뱅크를 표본화로 전환합니다.
근사 추적이 곧 근사 보안을 뜻해서는 안 됩니다. 표 크기, 계수기, 리프레시 구간, 전환 규칙은 행이 장치 임계치에 도달하기 전에 식별되거나 강화 모드를 시작하도록 정해야 합니다. 평균 적중률보다 최악 순서에 대한 증명이 중요합니다.
강화 모드는 공격이 있는 곳에 대역폭을 쓰는 방식
많은 행을 흩어 두드리는 공격에서는 전체 정확 표 대신 표본화와 예방 리프레시를 사용합니다. DRAM 작업은 늘지만 경량 모드의 근거가 무너진 서브뱅크만 비용을 냅니다. 다른 영역은 컨트롤러 내부 계수기만 갱신합니다.
공격자가 비용을 만들 수 있지만 상한이 있어야 합니다. 여러 서브뱅크를 번갈아 강화 모드로 만들 수 있으므로 최악 공격 대역폭, 정상 트래픽 지연, 공격 종료 뒤 복귀 시간을 공개해야 합니다. 정상 추적 기록에서 0인 추가 대역폭은 흔한 경우의 결과이지 공격 상한이 아닙니다.
정상 대역폭 0은 구체적인 성과
상시 표본화 방식은 작은 비율이라도 장비군 전체에서 유효 메모리 대역폭을 줄입니다. Sigries의 경량 모드는 컨트롤러 내부 계수기만 갱신했고 평가한 일반 작업에서는 추가 DRAM 명령을 만들지 않았습니다.
결과는 추적 기록과 표 크기에 의존합니다. 넓은 행 범위를 높은 속도로 쓰는 정상 분석 작업, 스트레스 시험, 공유 가속기는 악의 없이 강화 모드로 갈 수 있습니다. 오탐은 성능에 영향을 주되 보안을 낮추지는 않아야 합니다.
수십 항목도 서브뱅크, 채널, 컨트롤러 전체로 곱하면 상태가 커집니다. 지원 메모리 용량 전체의 SRAM, 접근 빈도, 누설 전력을 비교해야 합니다.
모드 전환 보정은 경계 시점의 누락을 막는 방식
강화 모드를 나가는 순간은 들어갈 때만큼 중요합니다. 원래 방식은 전환 경계를 사이에 두고 누적된 활성화를 놓칠 수 있었습니다. 각 모드 안에서는 임계치 아래여도 두 구간을 합치면 위험할 수 있습니다.
보정은 경량 추적이 상태를 완전히 이어받을 때까지 한 리프레시 구간 동안 두 모드를 함께 실행합니다. 추가 대역폭을 쓰지만 DRAM의 교란 상태가 모드 전환에서 초기화된 것처럼 취급하지 않습니다.
상태형 보안 하드웨어는 각 모드가 안전해도 상태를 넘기는 과정이 위험할 수 있습니다. 진입, 종료, 재설정, 리프레시, 전력 관리, 오류 복구를 함께 검증해야 합니다. 정오표 공개는 배포 계약을 명확히 하며 RTL과 펌웨어 개정판 점검으로 이어져야 합니다.
형식 검증은 공격 순서를 대상으로 해야 할 이유
임의 시험은 모드 경계를 넘거나 계수기 오차를 최대로 만드는 정확한 순서를 찾기 어렵습니다. 어떤 물리 행도 예방 조치 없이 보호 임계치를 넘지 않는다는 속성을 모든 표 상태와 전환 시점에 대해 검증해야 합니다.
모형에는 실제 DRAM 타이밍, 리프레시, 컨트롤러 큐, 주소 재매핑을 포함해야 합니다. 펌웨어가 공급하는 매개변수도 증명 범위에 들어가야 다른 가정으로 RTL 속성만 통과하는 일을 막습니다.
컨트롤러는 경량·강화 모드 전환, 강화 모드 체류, 예방 리프레시, 임계 여유 사건을 주소 노출 없이 셀 수 있습니다. 예상 밖 패턴은 정상 오탐, 공격, DIMM 설정 불일치를 찾는 근거가 됩니다.
전체 장비 배포에 필요한 버전 관리형 메모리 정보
Rowhammer 민감도는 DIMM 모델과 개정판마다 다릅니다. 온도, 노화, 패턴을 포함해 보수적인 임계치를 정하고 설치한 메모리에 맞는 컨트롤러 설정을 배포해야 합니다. 지원하지 않는 모듈이 느슨한 설정을 받지 않도록 장비 목록과 연결합니다.
계수기가 동작 중일 때 임계치나 모드 규칙을 바꾸면 또 다른 전환 누락 구간이 생길 수 있습니다. 안전한 업데이트는 트래픽을 비우거나 상태를 보존하고 새 설정이 자리 잡을 때까지 보수적으로 강화 모드를 유지해야 합니다.
강화 모드 전환이 정상 작업, 공격, 한계 상태의 장치 중 어디에서 비롯됐는지도 구분해야 합니다. 개인정보를 보호하면서 테넌트와 모듈별 사건을 연결해야 요청률 제한, 교체, 보안 조사가 올바른 원인을 따릅니다.
평가가 확정하는 범위
Azure Cobalt 200 구현은 시뮬레이션만 한 제안보다 강합니다. 일반 추적 기록이 경량 모드에 남은 결과는 정상 트래픽이 표본화 대역폭을 쓰지 않는다는 근거입니다. 작은 상태와 선택적 전환은 장비군 배포 가능성을 보여 줍니다.
모든 미래 작업이 경량 모드에 남거나 하나의 임계치가 모든 DRAM을 보호한다는 증명은 아닙니다. 공격 비용과 면적은 평가한 컨트롤러와 메모리 구성에서 읽어야 합니다. 또한 배포본이 정오표에서 요구한 두 모드의 중첩 실행을 포함하는지 확인해야 합니다.
구매·보안 검토에서는 DIMM 검증, 임계치와 여유, 주소 매핑, 용량당 상태, 정상·공격 대역폭, 전환 증명, 펌웨어 경로를 요구해야 합니다. 공격 테넌트와 정상 고대역폭 작업을 함께 실행해 격리도 재야 합니다.
컨트롤러가 DIMM 설정을 알 수 없거나 계수기 상태와 설정을 잃으면 보수적으로 동작해야 합니다. 강화 모드 진입, 낮은 임계치, 해당 메모리 격리는 성능 비용이 있지만 보안 계약을 지킵니다. 검증되지 않은 경량 모드를 계속 쓰면 오류 시 보호가 풀리는 동작이 됩니다.
재설정과 저전력 상태에서도 DRAM 교란 이력과 컨트롤러 계수기의 유지 기간이 다를 수 있습니다. 상태를 보존하거나 충분한 리프레시와 보수적 추적으로 불변 조건을 다시 만들어야 합니다. 공격자가 강화 모드를 지속해 가용성을 낮출 수 있으므로 보호를 끄지 말고 의심 영역의 요청률을 제한하거나 격리해야 합니다.
실제 메모리 제어기에 적용할 때는 보안성과 서비스 품질을 같은 시간축에서 확인해야 합니다. 공격성 접근이 여러 서브뱅크로 이동하면 강화 모드 전환이 연달아 일어나고, 그때 추가 리프레시가 정상 요청의 대기시간을 얼마나 늘리는지 측정해야 합니다. 평균 대역폭만으로는 짧은 집중 공격이 만든 꼬리 지연을 볼 수 없으므로 읽기·쓰기별 지연 백분위와 리프레시 대기열 길이를 함께 공개해야 합니다.
메모리 부품의 취약 기준이 갱신될 때도 같은 검증을 반복해야 합니다. 임계값을 낮추면 보호 여유는 커지지만 더 자주 강화 모드로 전환하고, 높이면 정상 비용은 줄지만 공격자가 이용할 수 있는 접근 횟수가 늘어납니다. 따라서 펌웨어가 선택한 값, 부품이 보증한 값, 운영자가 적용한 추가 여유를 구분해 기록해야 하며, 어느 하나라도 바뀌면 이전 시험 결과를 그대로 재사용해서는 안 됩니다.
정오표가 중요한 이유
공개 논문에는 정오표가 포함됐습니다. 원래의 강화 모드에서 경량 모드로 돌아가는 절차는 경계 시점의 위험한 행을 놓칠 수 있었습니다. 수정안은 강화 모드를 끝내기 전에 두 모드를 한 번의 추가 리프레시 구간 동안 함께 실행합니다. 운영 보안 하드웨어에는 형식 검증, 보수적 복구, 수정 가능한 설정 계약이 필요하다는 증거입니다.
선택적 방어는 비용과 보호 범위를 함께 통제하는 방식
Sigries는 평균 비용만 최소화하지 않고 정상과 공격 상황 모두에서 예측 가능한 동작을 목표로 합니다. 값싼 추적을 전환 조건으로 쓰고 증거가 있는 구역에만 대역폭을 쓰는 선택적 강화가 핵심입니다.
선택적 방어에 필요한 관찰 가능한 비용
선택적 Rowhammer 방어는 모든 메모리 영역에 가장 강한 완화 비용을 적용하지 않는다는 점에서 의미가 있습니다. 대신 운영자는 어떤 서브뱅크가 보호 상태에 들어갔는지, 얼마나 오래 유지됐는지, 어떤 증거가 전환을 일으켰는지, 추가 리프레시와 접근 지연이 얼마였는지 확인할 수 있어야 합니다. 이 운영 계측 정보가 없으면 방어가 실제 공격을 막았는지, 임곗값이 일부 작업만 조용히 느리게 만들었는지 구분할 수 없습니다.
검증에는 공격 패턴과 일반 메모리 스트레스 시험을 함께 사용해야 합니다. 통제된 공격 유도 패턴은 목표 임곗값 부근의 방어 범위를 확인하고, 장기간 운영 트레이스는 집중 접근 행, 치우친 메모리 배치, 온도 변화, 노화 조건에서 잘못 활성화되는 빈도를 보여 줍니다. 펌웨어와 DRAM 제조 배치가 바뀌면 안전한 임곗값도 다시 확인해야 합니다. 클라우드 구매자는 방어 기능 이름만 볼 것이 아니라 보호가 성립하는 동작 범위와 그 범위의 성능 및 에너지 비용을 요구해야 합니다.
출처와 저작권 안내
이 글은 독립적인 표현과 새 개념 도판으로 작성했습니다. 원문의 문장·도판·표를 재사용하지 않았습니다. Microsoft Research가 정오표가 포함된 전문을 공개했으며 공식 판본은 (c) IEEE 2026입니다.