IOMMU란 무엇인가
1. IOMMU가 무엇인가
Microsoft Learn의 정의:
An Input-Output Memory Management Unit (IOMMU) is a hardware component that connects a DMA-capable I/O bus to system memory. It maps device-visible virtual addresses to physical addresses, making it useful in virtualization.
IOMMU(I/O 메모리 관리 장치)는 DMA가 가능한 I/O 버스와 시스템 메모리 사이를 잇는 하드웨어이며, 디바이스가 보는 주소를 실제 물리 주소로 변환한다. CPU가 가상 주소를 물리 주소로 바꾸기 위해 MMU와 페이지 테이블을 사용하는 것과 정확히 같은 일을, 디바이스 측에서 한다.
위 그림은 WDDM의 GPU 사례를 그렸지만, 핵심은 단순하다. CPU 쪽에서는 가상 주소가 메모리 컨트롤러를 거쳐 시스템 메모리에 닿는다. GPU(또는 다른 DMA 디바이스) 쪽에서는 같은 프로세스의 가상 주소가 IOMMU를 거쳐 같은 시스템 메모리에 닿는다. 두 길은 같은 메모리를 향하지만, 각자의 변환 장치를 거친다.
2. “맵 레지스터” 추상과 IOMMU의 관계
Windows DMA API에는 맵 레지스터(map register) 라는 개념이 있다. HAL이 제공하는 (드라이버에는 불투명한) 자원으로, 디바이스가 접근 가능한 논리 주소를 실제 물리 페이지로 별칭(alias)한다. MS Learn은 그 실체가 “칩 내부 하드웨어 레지스터일 수도, 시스템 DMA 컨트롤러나 버스 마스터 어댑터 안의 레지스터일 수도, HAL이 시스템 메모리에 만든 가상 레지스터일 수도 있다”고만 명시한다.
현대 PC와 SoC에서 그 실체의 정체가 바로 IOMMU이다. 90년대 ISA 시절에는 정말로 칩 내부의 작은 하드웨어 레지스터 또는 HAL의 소프트웨어 별칭이 그 일을 했다. 2010년대 이후의 시스템에서는 CPU 칩셋 안에 내장된 본격적인 메모리 관리 장치, 즉 IOMMU가 그 역할을 흡수했다. 드라이버가 보는 API(맵 레지스터)는 그대로지만, 그 아래 하드웨어가 훨씬 강력하고 풍부해졌다.
Note
정리하자면, 맵 레지스터는 Windows DMA API의 추상이고, IOMMU는 그 추상을 현대적으로 구현한 하드웨어다. 둘은 서로 다른 층의 이름이지만 결국 같은 자리를 가리킨다.
3. CPU의 MMU와 디바이스의 IOMMU — 평행 구조
| CPU 측 | 디바이스 측 | |
|---|---|---|
| 변환 장치 | MMU | IOMMU |
| 변환 자료구조 | 페이지 테이블 (PTE) | IOMMU 페이지 테이블 |
| 변환 입력 | 가상 주소 | 디바이스/논리 주소 |
| 변환 출력 | 물리 주소 | 물리 주소 |
| 부수 기능 | 권한 비트, NX, 캐시 정책 | 디바이스별 보호, 도메인 분리 |
CPU의 MMU는 한 프로세스가 다른 프로세스의 메모리를 함부로 못 보게 막는다. IOMMU는 한 디바이스가 자기에게 할당되지 않은 메모리에 함부로 DMA를 못 하게 막는다. 이 단순한 평행이 IOMMU 활용처 대부분을 설명한다.
4. 왜 필요한가 — 네 가지 동기
4-1. 주소 변환
가장 오래된 동기. 32비트 PCIe 디바이스가 64비트 RAM에 접근해야 할 때, 또는 SoC GPU가 자기가 표현할 수 있는 주소 공간보다 큰 RAM에 접근해야 할 때, IOMMU가 디바이스가 다룰 수 있는 작은 주소 공간을 더 큰 물리 메모리에 매핑해 준다. 24비트 주소 라인의 ISA DMA 컨트롤러나 32비트 PCIe 디바이스 같은 사례를 일반화한 것이다.
4-2. 메모리 보호
IOMMU 없이 동작하는 DMA 디바이스는 시스템 RAM 어디든 자유롭게 읽고 쓸 수 있다. 디바이스 펌웨어에 버그가 있거나, 누가 일부러 악의적인 디바이스를 꽂으면, 커널 메모리든 다른 프로세스 메모리든 모두 노출된다.
IOMMU는 디바이스마다 별도의 페이지 테이블(이를 “도메인”이라 부른다)을 두어, 각 디바이스가 명시적으로 매핑된 페이지에만 접근할 수 있게 강제한다. 매핑되지 않은 주소로 DMA를 시도하면 IOMMU가 트랜잭션을 차단하고 OS에 폴트를 보고한다.
4-3. 가상화 (Hyper-V Discrete Device Assignment 등)
VM에 PCIe 디바이스를 직접 패스스루하려면, VM 안에서 실행되는 게스트 드라이버가 GPA(게스트 물리 주소)로 DMA를 발행하더라도, 호스트의 실제 물리 메모리(HPA)로 변환되어야 한다. IOMMU가 GPA→HPA 변환을 담당함으로써, 게스트는 자기가 실제 하드웨어를 직접 만지는 것처럼 동작하면서도 호스트 메모리를 침범하지 못한다. Hyper-V의 Discrete Device Assignment(DDA) 가 이 메커니즘 위에서 동작한다.
4-4. 보안 (Drive-by DMA 방어)
가장 현대적인 동기. PCIe 핫플러그 포트를 통한 메모리 탈취 공격을 IOMMU가 차단한다. 구체적인 위협 모델과 Windows의 방어 기능은 §6에 있다.
5. 벤더 구현
- Intel: VT-d (Virtualization Technology for Directed I/O) — 사용자/관리자가 BIOS/UEFI에서 활성화. Windows의 Kernel DMA Protection은 VT-d가 켜져 있어야 동작.
- AMD: AMD-Vi (또는 AMD IOMMU) — VT-d의 AMD 대응품. 같은 역할, 다른 구현.
- ARM: SMMU (System MMU) — ARM 진영의 표준 IOMMU. SoC 기반 Windows 디바이스(Surface Pro X 등)와 모바일 SoC에서 사용.
API 레벨에서는 Windows 드라이버가 이 차이를 알 필요가 거의 없다. HAL과 PnP 매니저가 어떤 IOMMU가 있는지를 보고 알아서 해 준다. 다만 Kernel DMA Protection 같은 상위 기능은 IOMMU가 켜져 있어야만 활성화되므로, 시스템 요구사항을 이해할 때 이 이름들이 등장한다.
6. Drive-by DMA 공격과 Kernel DMA Protection
위협 모델: Thunderbolt, USB4, CFexpress 같은 PCIe 핫플러그 포트에 연결된 디바이스는 정의상 DMA가 가능하다. 즉, OS나 CPU의 개입 없이 시스템 메모리를 읽고 쓸 수 있다. 공격자는 다음과 같이 한다.
- 노트북 사용자가 잠깐 자리를 비운다(잠금 화면 상태든, 잠그지 않은 상태든).
- 공격자가 미리 준비한 작은 DMA 디바이스(USB처럼 생긴 것)를 Thunderbolt 포트에 꽂는다.
- 디바이스는 시스템 메모리를 스캔하여 비밀번호, BitLocker 키, 자격 증명 캐시 등을 추출한다.
- 또는 메모리에 임의 코드를 주입해 잠금 화면을 우회하는 백도어를 설치한다.
이 공격은 분해도 필요 없고, 몇 분이면 끝난다. 이름하여 drive-by DMA attack이다. Thunderclap(2019)이 학술적으로 가장 잘 알려진 사례이다.
Windows의 방어 — Kernel DMA Protection: Windows 10 1803/1809부터 도입된 보안 기능으로, 다음과 같이 동작한다.
- OS는 IOMMU를 켜 둔 상태로 부팅한다.
- 외부 PCIe 포트(Thunderbolt, M.2 등)에 디바이스가 새로 꽂히면, OS는 그 디바이스의 드라이버가 DMA Remapping 호환 인지 검사한다.
- 호환되는 드라이버: IOMMU가 부여한 제한된 메모리 영역에서만 DMA를 수행하므로, 자유롭게 시작시킨다.
- 호환되지 않는 드라이버: 사용자가 로그인 또는 잠금 해제할 때까지 디바이스 시작 자체를 차단한다(IT 정책에 따라 영구 차단도 가능).
전제 조건은 다음과 같다 (OEM 문서에서 인용).
- 64비트 CPU + 가상화 확장(Intel VT-X 또는 AMD-V).
- IOMMU(Intel VT-D 또는 AMD-Vi)가 펌웨어에서 활성화.
- UEFI 펌웨어가 호환성을 보고해야 한다(ACPI Kernel DMA Protection Indicators). 펌웨어 측에서 부팅 시점의 DMA 격리, ExitBootServices() 시점의 IOMMU 상태 보존 등을 책임진다. 같은 칩셋이라도 노트북마다 켜지고 안 켜지는 차이는 보통 이 펌웨어 지원의 유무에서 갈린다.
Important
Kernel DMA Protection은 OS가 부팅된 이후의 drive-by DMA 공격만 막는다. 부팅 시점의 공격은 시스템 펌웨어/BIOS의 책임이다. 또한 1394/FireWire, PCMCIA, CardBus, ExpressCard 경유 공격은 보호 범위 밖이다.
7. 드라이버 관점: DMA Remapping 호환성
Note
시스템 차원의 정책인 Kernel DMA Protection과, 개별 드라이버의 DMA Remapping 호환성은 별개의 개념이다. 시스템의 Kernel DMA Protection이 꺼져 있어도, 드라이버가 opt-in하고 VT-d/AMD-Vi가 활성화되어 있으면 그 드라이버는 IOMMU의 보호를 받는다(MS Learn FAQ).
드라이버가 IOMMU와 잘 어울리는지를 INF에 명시적으로 선언해야 한다. Windows에는 두 가지 메커니즘이 있고, 24H2를 기점으로 권장이 바뀌었다.
7-1. 현재 (Windows 24H2 이상): per-device 방식
24H2 이후 새로 작성하는 드라이버는 이 방식을 써야 한다. 디바이스 enumeration 섹션에 다음을 추가한다.
[MyDriver_Device.NT.HW]
AddReg=DMA_Remapping_OptIn_AddReg
[DMA_Remapping_OptIn_AddReg]
HKR,"DMA Management","RemappingSupported",0x00010001,1
DMA Management\RemappingSupported 값:
| 값 | 의미 |
|---|---|
| 0 | Opt-out. 디바이스/드라이버가 DMA Remapping과 호환되지 않는다. |
| 1 | Opt-in. 완전 호환. |
| 키 없음 | 시스템이 정책을 결정. |
선택적으로 DMA Management\RemappingFlags 를 추가하여 활성화 조건을 좁힐 수 있다.
| 값 | 의미 |
|---|---|
| 0 | RemappingSupported가 1이면 무조건 Opt-in. |
| 1 | RemappingSupported가 1이면 조건부 Opt-in: 외부 디바이스(예: Thunderbolt)이거나 Driver Verifier의 DMA 검증이 켜진 경우에만. |
| 키 없음 | 0과 동일. |
이 키들은 enumeration 트리(HKLM\SYSTEM\CurrentControlSet\Enum\PCI\<device instance path>\Device Parameters\DMA Management) 아래에 만들어진다.
7-2. 레거시 (Windows 11 23H2 이하): per-driver 방식
서비스 설치 섹션에 다음을 추가한다.
[MyServiceInstall_AddReg]
HKR,Parameters,DmaRemappingCompatible,0x00010001,1
DmaRemappingCompatible 값:
| 값 | 의미 |
|---|---|
| 0 | Opt-out. 호환되지 않음. |
| 1 | Opt-in. 완전 호환. |
| 2 | 조건부 Opt-in. 외부 디바이스이거나 Driver Verifier DMA 검증이 켜진 경우에만 활성화. |
| 3 | Opt-in (Windows 11에서 추가). Windows 10에서는 자동으로 2로 강등(graceful degradation). |
| 키 없음 | 시스템이 정책을 결정. |
7-3. 두 방식의 관계와 공통 요건
- per-device 키가 있으면 레거시 키는 무시된다 (
RemappingSupported가 설정되어 있으면DmaRemappingCompatible은 무시). - 두 방식 모두, 호환성을 만족시키려면 표준 인터페이스 중 하나를 통해서만 DMA를 수행해야 한다.
- WDF DMA 인터페이스 (KMDF의 DMA enabler / DMA transaction 객체)
- WDM DMA 인터페이스 (
IoGetDmaAdapter이하) - NDIS DMA 인터페이스
- 물리 주소를 직접 디바이스에 프로그래밍하거나, 표준 API를 우회해 페이지 테이블을 직접 만지면 IOMMU가 즉시 잡아낸다.
Warning
그래픽 드라이버는 위 INF 메커니즘으로 DMA remapping을 지원하지 않는다(MS Learn 명시). GPU의 IOMMU 활용은 별도의 WDDM 경로(IoMmu 모델, IOMMU DMA remapping)를 따르며, 이는 Windows 11 22H2의 WDDM 3.0에서 도입되었다. Windows 10에서는 GPU 측 IOMMU 활용 자체가 지원되지 않는다.
Microsoft가 제공하는 inbox 드라이버 중 USB XHCI(3.x), Storage AHCI/SATA, Storage NVMe 드라이버가 이 호환성을 지원한다(출처: Kernel DMA Protection FAQ).
7-4. 호환 여부 확인하기
특정 드라이버가 호환되는지 확인하려면, 디바이스 관리자에서 해당 디바이스 속성 → 자세히 → “DMA Remapping Policy”를 본다. 값이 2이면 호환, 0이나 1이면 비호환이다.
Note
디바이스 관리자에 표시되는 정책 값(0/1/2)은 DEVPKEY_Device_DmaRemappingPolicy의 반환 값이며, INF 디렉티브의 값(0/1/2/3)과는 의미 체계가 다르다. INF에 1을 적었더라도 디바이스 관리자에는 2로 보일 수 있다. 두 값을 직접 비교하지 말 것.
8. DRIVER_VERIFIER_DMA_VIOLATION
1
2
3
4
5
DRIVER_VERIFIER_DMA_VIOLATION (e6)
An illegal DMA operation was attempted by
a driver being verified.
Arguments:
Arg1: 0000000000000026, IOMMU detected DMA violation.
Driver Verifier의 DMA 검증을 켠 상태에서, 드라이버가 IOMMU에 등록되지 않은 영역으로 DMA를 시도하면 IOMMU가 폴트를 일으키고 시스템은 0xE6 버그 체크로 멈춘다. 인자 0x26은 “IOMMU가 직접 위반을 검출했다”는 의미다.
원인은 보통 다음 중 하나다.
MapTransfer/PutScatterGatherList로 매핑을 정상적으로 끝내기 전에, 또는 끝낸 뒤에 그 영역으로 DMA를 발행함.- 직접
MmGetPhysicalAddress로 얻은 물리 주소를 디바이스에 그대로 넘겨 줌(IOMMU 입장에서는 등록된 매핑이 없어 위반). AllocateCommonBuffer없이 임의로 할당한 비페이지 메모리의 물리 주소를 디바이스에 노출함.
IOMMU가 활성화된 시스템에서는 Windows DMA API를 우회하면 그냥 충돌한다. 90년대였다면 운 좋게 동작했을 코드가 부팅 직후 BSOD를 부른다.
9. 현재 시스템에서 IOMMU/Kernel DMA Protection 상태 확인하기
msinfo32.exe를 실행 → “Kernel DMA Protection” 항목을 본다. ON 이면 IOMMU + 정책이 모두 살아 있는 상태.- Windows Security → 디바이스 보안 → 코어 격리 세부 정보 → “메모리 액세스 보호”.
- 펌웨어에서 가상화(Intel VT-X / AMD-V)와 VT-d/AMD-Vi가 모두 켜져 있어야 한다. Hyper-V 기능을 켜둔 경우 일부 항목이 숨겨질 수 있다.
출처
- IoMmu model — IOMMU의 정의 (본문 인용)와 본문 그림 출처
- IOMMU DMA remapping — WDDM 3.0의 IOMMUv2와 GPU별 논리 매핑
- Kernel DMA Protection — drive-by DMA 위협 모델, FAQ, 확인 방법
- Kernel DMA Protection (Memory Access Protection) for OEMs — 플랫폼 요구사항 (CPU, IOMMU 벤더 이름)
- Enable DMA remapping for device drivers —
DmaRemappingCompatibleINF 디렉티브 값 - Stop code DRIVER_VERIFIER_DMA_VIOLATION when Kernel DMA Protection is enabled — 0xE6 버그 체크
- DSD for PCIe Root Ports — 어떤 PCIe 포트가 외부/노출된 것으로 분류되어 보호 대상이 되는지
- Enabling PCI Express Native Control — Kernel DMA Protection의 전제 조건인 ACPI
_OSC핸드셰이크
더 깊이 다루는 자료:
- Thunderclap (NDSS 2019) — drive-by DMA 공격을 학술적으로 가장 체계적으로 분석한 논문. IOMMU만 켜져 있다고 끝이 아님을 보여 준 케이스.
- Intel VT-d 사양서, AMD I/O Virtualization Technology (IOMMU) 사양서 — IOMMU 페이지 테이블 포맷, 도메인, PASID 등을 하드웨어 레벨에서 다룸.
- Linux Kernel Documentation:
Documentation/admin-guide/iommu.rst및drivers/iommu/— Windows 외의 시점에서 같은 하드웨어가 어떻게 추상화되는지 비교해 보면 IOMMU의 본질이 더 잘 보인다.