Атаки DMA 101: як IOMMU не дає PCIe-пристрою заволодіти вашою оперативною пам’яттю

February 20, 2026 • February 20, 2026 • Читання: 5 хв • Views: 0

Було корисно?

Ваш процесор може мати увімкнені всі сучасні захисти — захист ядра, SELinux/AppArmor, зашифровані диски, виміряне завантаження — і
один PCIe-пристрій все одно може читати й записувати вашу оперативну пам’ять без запиту дозволу. Це не гіпотеза. Це DMA.

Якщо ви керуєте флотами серверів, збираєте безпечні робочі станції або робите passthrough PCIe у віртуалізованих середовищах, IOMMU — це один із тих
«або воно ввімкнене й налаштоване правильно, або ви себе обманюєте» механізмів. Конкретно: що таке DMA-атаки, що IOMMU
насправді забезпечує і як переконатися, що ваша система робить те, що ви думаєте.

DMA простими словами: чому пристрої можуть торкатися вашої пам’яті

DMA означає «Direct Memory Access» (прямий доступ до пам’яті). Назва чесна: пристрій передає дані в/з системної пам’яті без того,
щоб процесор копіював їх байт за байтом. Процесор налаштовує передачу (буфери, адреси, розміри), потім пристрій стає майстром шини
і переміщує вантаж. Саме так диски, GPU, мережеві контролери та швидкі контролери досягають заявлених маркетингових показників.

Проблема безпеки теж чесна: якщо пристрій може записувати в довільну фізичну пам’ять, він може перезаписати код ядра,
змінити таблиці сторінок, вкрасти ключі та прочитати все, що ви вважали «захищеним» моделлю привілеїв CPU. Рівні кілець процесора не
поширюються на PCIe-пристрій. Шина не переймається вашими почуттями.

Добросовісний драйвер налаштовує пристрій DMA лише в буфери, які виділила ОС. Але «добросовісність» — це політичний вибір,
і злоумисники люблять політику. Зловмисний периферійний пристрій, скомпрометоване мікропрограмне забезпечення або баг драйвера можуть перетворити DMA на
«доступ до пам’яті без нагляду».

Ви не закриєте це кращими ACL. Потрібне апаратне забезпечення між пристроями та пам’яттю. Цей захист — IOMMU.

Навіщо потрібен DMA (і чому його не можна просто заборонити)

Якби процесор мав копіювати кожен пакет від мережевої карти в RAM і кожен блок диска в кеш вручну, ви б або:
(a) отримали сміховинну пропускну здатність, або (b) витрачали ядра на переміщення даних замість виконання роботи. Сучасні системи використовують DMA плюс
приглушення переривань, черги пар, і scatter-gather, щоб тримати CPU осторонь.

У зберіганні та мережах зокрема DMA — це як досягати лінійної швидкості та низької затримки. NVMe використовує черги подачі/завершення в пам’яті; пристрій DMA-ить завершення в RAM.
Швидкі мережеві карти DMA-ять пакети в hugepages. RDMA прямо каже: «дозвольте мережевій карті читати/писати пам’ять додатка». Все це чудово — поки ви не згадаєте, що
пристрій знаходиться за межами області привілеїв CPU.

Дві моделі загроз, які часто плутають

Фізичний нападник із пристроєм: хтось підключає пристрій до Thunderbolt/PCIe, або замінює внутрішню плату,
або зловживає відкритим портом у публічному терміналі чи кімнаті серверів. Їм не потрібен ваш пароль, якщо вони можуть читати RAM.

Програмний нападник, що керує DMA пристрою: скомпрометований драйвер, експлуатована вразливість ядра у стеку пристрою,
зловмисна VM із PCI passthrough або шкідливе ПЗ у мікропрограмі пристрою. Нападнику не потрібен фізичний доступ; потрібен шлях для програмування DMA-движків.

IOMMU допомагає в обох випадках, але пом’якшення та операційні звички відрізняються.

Як DMA-атаки відбуваються в реальному житті

DMA-атаки не магія. Це ланцюжок: отримати пристрій, який може ініціювати DMA, підключити його до шини, а потім спрямувати його на пам’ять.
Цікаво, наскільки легко може бути отримати такий пристрій на місце, і наскільки багато можна зробити, отримавши доступ до RAM.

Шлях атаки 1: зовнішні високошвидкісні порти

Thunderbolt фактично є зовнішнім PCIe. Це його особливість. Це також ризик: підключіть пристрій — і потенційно ви додаєте майстра шини з DMA.
Сучасні системи додають шари, такі як рівні безпеки Thunderbolt і авторизація ОС, але це не те ж саме, що «цей пристрій може DMA лише в сандбокс».

Якщо IOMMU вимкнено або неправильно налаштовано, зловмисний пристрій може просканувати фізичну пам’ять на предмет облікових даних, структур ядра або таблиць сторінок.
Якщо пощастить — «лише» витік секретів. Якщо не пощастить — пристрій запише й перетворить витік на постійність.

Шлях атаки 2: скомпрометоване мікропрограмне забезпечення пристрою

У вашої мережевої карти є firmware. У SSD є firmware. У GPU є firmware. У «прості» контролера USB є firmware.
Firmware може оновлюватися, іноді автоматично, іноді через утиліти від вендора, іноді через драйвер.

Якщо нападник змусить виконуватися свій код у PCIe-пристрої, цей пристрій стає немоніторованим DMA-движком. ОС не може інспектувати його так само, як процес.
Саме тому IOMMU вважають базовим елементом у системах високої впевненості: він переміщує межу довіри ближче до RAM.

Шлях атаки 3: віртуалізація та passthrough

PCI passthrough (VFIO) дає VM прямий доступ до фізичного пристрою. Мета — продуктивність і доступ до функцій.
Без IOMMU passthrough не «небезпечно». Це «ви дали VM навантажувач і спрямували його на пам’ять хоста».

З IOMMU, налаштованим правильно, пристрій обмежено пам’яттю гостя. Це вся модель безпеки за безпечним passthrough.

Шлях атаки 4: баги драйвера і «DMA у неправильне місце»

Не кожен інцидент DMA — це нападник у капюшоні. Багато випадків: «драйвер неправильно запрограмував адресу DMA», або «пристрій записав за межі кільцевого буфера», або «баг у IOVA-мепінгу спричинив корупцію пам’яті».

IOMMU може перетворити ці баги з «тихої корупції» на «помилку IOMMU і обмежену зону ураження». Це перемога навіть
коли ви не вважаєте себе під атакою.

Що IOMMU справді робить (і чого не робить)

IOMMU — це блок керування пам’яттю для вводу/виводу. Процесор має MMU, що відображає віртуальні адреси у фізичну пам’ять з правами доступу.
IOMMU відображає адреси, видимі пристроям, у фізичну пам’ять, також з правами доступу. Пристрої не обов’язково «говорять» віртуальними адресами, тому IOMMU
дає їм адресний простір (IOVA) і контролює, до чого вони можуть дістатися.

Основний механізм: трансляція й перевірки дозволів для DMA

Коли пристрій намагається виконати DMA на адресу, ця адреса інтерпретується в домені, який контролює ОС. IOMMU транслює
цей IOVA в фізичну адресу і перевіряє дозволи. Якщо мапінгу немає або дозволи не дозволяють операцію, IOMMU блокує її і зазвичай повідомляє про помилку.

На практиці це означає:

Пристрої не можуть DMA у довільну RAM просто тому, що вони — майстри шини.
Кожен пристрій (або група пристроїв) може бути поміщений у домен ізольованості.
Віртуалізація може призначити пристрій гостю і обмежити DMA пам’яттю гостя.
Баги драйверів призводять до голосних помилок замість тихої корупції — якщо ввімкнено режим контролю.

IOMMU ≠ магічний щит

IOMMU не врятує вас, якщо ви ніколи його не вмикаєте, або якщо ввімкнули, але залишили пристрої в домені з identity-мепінгом,
де IOVA==physical для «сумісності». Він також не захистить від пристрою, якому дозволено писати в певний буфер, якщо ви зберігаєте там секрети. Принцип найменших привілеїв усе ще важливий.

Він також не може зупинити зловмисний пристрій від завдання шкоди в межах дозволеної області. Якщо ви надали GPU доступ до половини RAM задля «продуктивності» — це ваш вибір.
IOMMU сумлінно це забезпечить.

Intel VT-d, AMD-Vi і як Linux називає речі

На Intel IOMMU зазвичай називають VT-d. На AMD — AMD-Vi (іноді просто IOMMU, іноді «IVRS» у ACPI-контексті).
У логах Linux ви побачите «DMAR» на платформах Intel і «AMD-Vi» або «IOMMU» на AMD.

Linux використовує API та драйвери IOMMU. Пристрої призначаються до IOMMU groups, що має велике значення для віртуалізації:
група — найменша гранулярність ізоляції, яку ядро може безпечно забезпечити на основі того, як пристрої підключені і як
реалізовано ACS (Access Control Services) у вашій PCIe-топології. Якщо дві функції можуть перехоплювати трафік одна одної,
вони опиняються в одній групі, і ви не можете безпечно передати одну без іншої.

Продуктивність: витрати реальні, але частіше менші, ніж ви боїтесь

Трансляція IOMMU додає накладні витрати: є кеш трансляцій (IOTLB), ходи таблиць сторінок і додаткові перевірки.
Пристрої з високою пропускною здатністю можуть його навантажувати. Але сучасні IOMMU швидкі, і Linux має пом’якшення, як-от батчинг, hugepages
та режим passthrough на рівні пристрою, коли це доречно.

Операційна позиція, яку я рекомендую: вважайте повне примусове застосування IOMMU за замовчуванням. Відмовляйтесь від нього по пристрою лише після вимірювань і лише коли модель загроз це дозволяє.
«Ми вимкнули його, бо хтось сказав, що воно повільніше» — це не інженерне рішення. Це чутка з root-привілеями.

Одна цитата, що тримає вас у реальності

парафразована думка — Вернер Фогельс: будуйте так, щоб відмова була безпечною; не припускайте, що відмов не буде.

Цікаві факти та історичний контекст

Ось конкретні історичні факти, які пояснюють, чому ця тема що кілька років знову виникає, немов поганий оновлення залежностей.

DMA передує сучасним моделям безпеки ОС. Ранні системи використовували DMA, щоб зняти навантаження з повільних процесорів; безпека не була головним фактором дизайну.
PCI зробив bus mastering звичним. PCI і пізніше PCIe стандартизували високопродуктивний доступ пристроїв, зробивши DMA стандартною можливістю для багатьох контролерів.
FireWire був раннім «зовнішнім DMA» дзвінком тривоги. IEEE 1394 відкрив доступ типу DMA зовні так, що це здивувало користувачів ноутбуків і команди безпеки.
VT-d/AMD-Vi дозріли разом із віртуалізацією. Вендори апаратного забезпечення сильно інвестували, тому що безпечне призначення пристроїв в VMs цього вимагало.
«Групи IOMMU» формуються топологією PCIe. Групування — не забаганка Linux; воно відображає, які пристрої можна ізолювати з урахуванням містків, ACS і маршрутизації.
Thunderbolt популяризував зовнішній PCIe для споживачів. Зручно для док-станцій і eGPU; але також подарунок у вигляді вектора DMA, якщо ви його не обмежите.
Помилки DMA корисні для діагностики. В продакшені логи помилок IOMMU виявляли баги драйверів, що інакше виглядали б як випадкові помилки RAM.
Деякі системи роками постачалися з IOMMU вимкненим за замовчуванням. Побоювання щодо сумісності й продуктивності були реальними; так само як і технічний борг у безпеці.
Сучасні ядра підтримують захист DMA на рівні пристрою. Ядро може обирати строгі або відкладені стратегії мапінгу, а деякі пристрої можуть працювати в режимі «passthrough», тоді як інші ізольовані.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент, спричинений неправильною припущенням

Середня SaaS-компанія тримала приватний кластер для CI-навантажень. Розробники могли створювати VMs з GPU passthrough для прискорення збірок і деяких ML-тестів. Команда платформи припустила, що оскільки хости в захищеній стойці і VMs «внутрішні», головний ризик — шумні сусіди і витрати.

Дослідник із безпекової команди зробив те, що роблять хороші дослідники: запитав «що як VM ворожа?» Отримали дозвіл тестувати в стендовому середовищі, що відтворював апаратне забезпечення продакшену. У стенді вони передали запасну мережеву карту гостю, щоб перевірити поведінку SR-IOV. Гість міг DMA у пам’ять хоста. Не завжди. Не стабільно. Але достатньо, щоб продемонструвати читання структур даних, які ніколи не мали перетинати ту межу.

Корінна причина не була екзотичною. У BIOS було доступне «Intel VT-d», але воно було вимкнене. Документація щодо провізії вказувала «увімкніть VT-x» для віртуалізації, і хтось припустив, що VT-x означає VT-d. Ні. Ви можете запускати VMs без ізоляції DMA, поки не почнете робити passthrough або підключати щось зле.

Виправлення було простим: увімкнути VT-d, застосувати IOMMU в ядрі та оновити стандарт провізії так, щоб розгортання, що не відповідає вимогам, не проходило. Найболючіше було аудиторське: потрібно було повторно верифікувати весь кластер, бо «ми припустили, що воно ввімкнене» — не доказ.

Урок, що лишився: якщо ви експлуатуєте віртуалізовану інфраструктуру і плануєте passthrough, SR-IOV або щось «ближче до заліза», ставте «IOMMU увімкнено і строгий режим» як жорстку вимогу, а не налаштування.

Міні-історія 2: Оптимізація, що дала зворотний ефект

Інша компанія виконувала заточені під затримку торгові аналітики на bare metal із спеціалізованими мережевими картами. Вони цінували мікросекунди як нормальні люди цінують повітря. Під час оптимізації хтось запропонував увімкнути «IOMMU passthrough» системно, аргументуючи, що IOMMU «лише додає накладні витрати», а системи й так фізично захищені.

Вони протестували пропускну здатність і побачили невеликі покращення на синтетичному бенчмарку. Переможна хода. Зміна розгорнулась ширше. Через кілька днів з’явилися спорадичні краші: паніки ядра, корупція sk_buffs, дивні помилки алокатора. Схоже на погану RAM. Пахло як нестабільний драйвер. Відтворювалося лише під піковим навантаженням.

Справжня причина була прозаїчною і жорстокою: драйвер іноді неправильно програмував DMA-мепінг у рідкісному випадку переповнення. При строгому IOMMU вихід за межі спричинив би фолт. У режимі passthrough воно писало у суміжну пам’ять і перетворювало відновлюваний баг на тиху корупцію.

Вони відкотили «оптимізацію», і краші зникли. Пізніше працювали з вендором над виправленням драйвера і повторно бенчмаркували з суворішим мапінгом, але з більшими IOVA-сторінками і кращим розміром черги. Вони повернули більшу частину продуктивності без перетворення пам’ятевої системи на вільний доступ.

Урок: IOMMU — не лише функція безпеки. Це ремінь безпеки для DMA. Вимкнути його може зробити автомобіль швидшим на прямій. Поки не зустрінете реальність.

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

Організація охорони здоров’я мала політику: кожна командна лінія ядра керувалася централізовано, а кожен завантажувальний лог хоста сканувався на конкретні підписи. Один з підписів — «IOMMU enabled» і «DMAR: IOMMU enabled» (Intel) або «AMD-Vi: IOMMU enabled» (AMD). Якщо цього не було, хост ізолювали від чутливих робочих навантажень.

Під час планової оновлення апаратної частини партія серверів прибула з іншими BIOS-значеннями за замовчуванням, ніж попереднє покоління. Хости завантажилися. Вони приєдналися до інвентарю. Пройшли базові перевірки працездатності. Але сканер логів відзначив відсутність увімкнення IOMMU на частині серверів.

Початкова реакція команди проекту була роздратованою. «Вони в тій же закритій кімнаті». «У нас немає Thunderbolt». «Пофіксимо пізніше». SRE на виклику сказав ні, бо суть базових налаштувань — їх не дискутують о 2-й ночі. Вони зупинили розгортання і виправили налаштування BIOS перед тим, як пересунути робочі навантаження.

Через два тижні підрядник був спійманий на підключенні неавторизованого PCIe-пристрою до лабораторної машини в іншому середовищі. Той інцидент не вплинув на продакшен, але нагадав, що фізичні припущення з часом деградують. Сухий контроль логів запобіг класу «нам не здавалося, що це важливо» помилок у регульованих системах.

Урок: надійність не здобувається героїчними діями. Вона здобувається нудною автоматизацією, яка не піддається торгу.

Практичні завдання: команди, виводи та рішення

Нижче — практичні перевірки, які ви можете виконати в Linux. Кожне завдання містить: команду, що типовий вивід означає,
і рішення, яке ви приймаєте. Це не академічно; це ті самі кроки, які ви застосуєте, коли чуєте «IOMMU увімкнено?» або «чому VFIO падає?» або «чому мережевий контролер зависає під навантаженням?»

Завдання 1: Перевірте параметри завантаження ядра для ввімкнення IOMMU

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.8.0 root=/dev/mapper/vg0-root ro quiet intel_iommu=on iommu=pt

Що це означає: intel_iommu=on запитує Intel VT-d. iommu=pt — це «passthrough»
для пристроїв, що не використовують DMA API мапінги (часто вибір заради продуктивності).

Рішення: Якщо ви захищаєтесь від DMA, уникайте системного iommu=pt, якщо ви не розумієте,
які пристрої будуть у passthrough і навіщо. Віддавайте перевагу строгій/за замовчуванням трансляції, коли модель загроз включає ворожі пристрої.

Завдання 2: Підтвердити, що IOMMU справді ініціалізовано (Intel DMAR)

cr0x@server:~$ dmesg | grep -E 'DMAR|IOMMU'
[    0.842113] DMAR: IOMMU enabled
[    0.842981] DMAR: Host address width 46
[    0.843540] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.848992] DMAR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[    0.850220] DMAR: Interrupt remapping enabled

Що це означає: Ви хочете бачити «IOMMU enabled» і бажано «Interrupt remapping enabled.»
Перенаправлення переривань важливе, бо MSI/MSI-X також можна зловживати; remapping зменшує зону ураження.

Рішення: Якщо цього немає, ви не захищені. Спочатку виправте налаштування BIOS/UEFI, потім параметри ядра.

Завдання 3: Підтвердити, що IOMMU ініціалізовано (AMD-Vi)

cr0x@server:~$ dmesg | grep -E 'AMD-Vi|IOMMU'
[    0.611234] AMD-Vi: IOMMU performance counters supported
[    0.611290] AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
[    0.611542] AMD-Vi: Extended features (0xf77ef22294ada): PPR NX GT IA GA PC GA_vAPIC
[    0.611910] AMD-Vi: Interrupt remapping enabled

Що це означає: AMD IOMMU активний і перенаправлення переривань увімкнено.

Рішення: Якщо ви цього не бачите, вважайте хост таким, що не відповідає вимогам для passthrough та для середовищ з високим ризиком фізичного доступу.

Завдання 4: Перевірте, чи присутній вигляд файлової системи IOMMU

cr0x@server:~$ ls -1 /sys/kernel/iommu_groups | head
0
1
10
11
12

Що це означає: Існують групи IOMMU. Це хороший знак, хоча не повна гарантія строгого режиму.

Рішення: Якщо цей шлях не існує, або IOMMU не ввімкнено, або ваша конфігурація/ядро це ховає. Розслідуйте перед спробою VFIO.

Завдання 5: Перелічити пристрої та їхні IOMMU групи (планування passthrough)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}"; lspci -nns $(basename -a $g/devices/*); echo; done
Group 7
00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:7a06]

Group 8
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684]
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:22ba]

Що це означає: Ваш GPU і його HDMI-аудіофункція в одній групі. Це нормально. Якщо GPU
ділить групу з випадковими чіпсетними пристроями — це тривожний сигнал для ізоляції при passthrough.

Рішення: Передавайте лише цілі групи. Якщо групування надто грубе, розгляньте інші слоти,
увімкнення ACS у BIOS або зміну апаратної платформи. Уникайте «патчів ACS override» у продакшені, якщо ви не готові до компромісів з безпекою.

Завдання 6: Переконатися, що VFIO використовує домен IOMMU для переданого пристрою

cr0x@server:~$ dmesg | grep -E 'vfio|IOMMU' | tail -n 20
[  124.332910] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[  124.341210] vfio_iommu_type1: DMA mapping enabled
[  124.341985] vfio_pci: add [10de:2684[ffffffff:ffffffff]] class 0x000000/00000000

Що це означає: vfio_iommu_type1 вказує, що бекенд VFIO IOMMU використовується, маплячи DMA для гостя.

Рішення: Якщо VFIO скаржиться на відсутність IOMMU, не «примушуйте» його. Виправте конфігурацію платформи. Інакше ви будуєте кімнату-вихід без стін.

Завдання 7: Перевірте, чи ядро в строгому режимі DMA або використовує відкладений мапінг

cr0x@server:~$ cat /sys/module/iommu/parameters/strict
Y

Що це означає: Строгий режим увімкнено (негайний unmap, жорсткіший захист, іноді вища накладна вартість).
На деяких системах ви можете побачити N, що означає відкладений/лінивий unmap.

Рішення: Для систем з високими вимогами безпеки віддавайте перевагу strict. Для пристроїв з чисто продуктивнісними задачами у керованому середовищі
можна дозволити нестрогий режим, якщо ви розумієте ризики і виміряли вигоди.

Завдання 8: Виявлення помилок IOMMU (сигнал «ваш пристрій щось зробив неправильно»)

cr0x@server:~$ dmesg | grep -i -E 'DMAR:.*fault|IOMMU.*fault|AMD-Vi:.*event' | tail -n 20
[ 9231.112233] DMAR: DRHD: handling fault status reg 2
[ 9231.112241] DMAR: [DMA Read] Request device [01:00.0] fault addr 0x0000000f3a200000 [fault reason 0x06] PTE Read access is not set

Що це означає: Пристрій спробував DMA читання адреси без дозволу. Це може бути атака, баг драйвера
або гонка під час скидання пристрою.

Рішення: Повторювані помилки трактуйте як інцидент. Ідентифікуйте пристрій, оновіть драйвери/firmware і розгляньте виведення пристрою з експлуатації.
Якщо це поодинокий випадок під час скидання пристрою, корелюйте з логами та апаратними подіями.

Завдання 9: Ідентифікувати пристрій за BDF і співвіднести його з драйвером

cr0x@server:~$ lspci -s 01:00.0 -nnk
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:5123]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau

Що це означає: Пристрій на 01:00.0 зв’язано з vfio-pci. Це означає, що ви плануєте його призначити.

Рішення: Якщо ви не мали наміру призначати його, виправте прив’язку драйвера. Якщо мали — переконайтеся, що група ізольована і гість налаштований коректно.

Завдання 10: Перевірити, чи перенаправлення переривань активне (безпека + стабільність)

cr0x@server:~$ dmesg | grep -i 'remapping' | head
[    0.850220] DMAR: Interrupt remapping enabled
[    0.850232] DMAR-IR: Enabled IRQ remapping in x2apic mode

Що це означає: IRQ remapping увімкнено; це допомагає стримувати пристрої, які можуть генерувати переривання нетиповим чином.

Рішення: Якщо не увімкнено, перевірте BIOS і параметри ядра. Деякі платформи вимикають його при некоректній конфігурації; виправте це перед довірою до passthrough.

Завдання 11: Підтвердити наявність контролера Thunderbolt і як він авторизується

cr0x@server:~$ lspci | grep -i thunderbolt
3d:00.0 USB controller: Intel Corporation Thunderbolt 4 NHI [Maple Ridge]

Що це означає: У вас є контролер Thunderbolt. Це зовнішня точка входу PCIe.

Рішення: На ноутбуках/робочих станціях поєднуйте IOMMU з політикою безпеки Thunderbolt. На серверах розгляньте вимкнення зовнішніх PCIe-подібних портів, якщо вони не потрібні.

Завдання 12: Перевірити стан kernel lockdown / Secure Boot (допомагає застосовувати політику, але не IOMMU сам по собі)

cr0x@server:~$ cat /sys/kernel/security/lockdown
integrity

Що це означає: Kernel lockdown в режимі integrity (типово під Secure Boot). Це може зменшити можливості root виконувати деякі ризикові дії, як-от довільний доступ до пам’яті ядра.

Рішення: Не плутайте це з захистом DMA. Вони доповнюють одне одного. Тримайте це увімкненим для довірених робочих навантажень, але все одно перевіряйте IOMMU.

Завдання 13: Переглянути DMA mask / можливості адресації (допомагає пояснити помилки мапінгу)

cr0x@server:~$ cat /sys/bus/pci/devices/0000:01:00.0/dma_mask_bits
64

Що це означає: Пристрій може DMA у 64-бітні адреси. Пристрої з обмеженням до 32-біт можуть викликати bounce buffering
і проблеми з продуктивністю, і вони підвищують навантаження на зони низької пам’яті.

Рішення: Якщо ви бачите 32-біт на пристрої з високою пропускною здатністю, очікуйте накладних витрат. Розгляньте заміну апаратури або стратегії pin/bounce залежно від стеку.

Завдання 14: Перевірити hugepages (налаштування продуктивності для DMA-навантажень)

cr0x@server:~$ grep -E 'HugePages|Hugepagesize' /proc/meminfo
HugePages_Total:      2048
HugePages_Free:       1980
HugePages_Rsvd:         12
Hugepagesize:        2048 kB

Що це означає: Налаштовано 2MB hugepages. Великі сторінки можуть зменшити накладні витрати IOMMU, бо зменшують кількість IOVA-трансляцій для великих буферів.

Рішення: Якщо ви боретеся з промахами IOTLB або високими накладними витратами мапінгу DMA, розгляньте hugepages — але лише після вимірювань і впевненості, що ваш додаток виграє.

Завдання 15: Спостерігати повідомлення ядра, пов’язані з IOMMU, під час скидань пристрою

cr0x@server:~$ journalctl -k -f
Feb 04 12:11:19 server kernel: vfio-pci 0000:01:00.0: Resetting device
Feb 04 12:11:19 server kernel: DMAR: [DMA Write] Request device [01:00.0] fault addr 0x0000000f3a210000 [fault reason 0x05] PTE Write access is not set

Що це означає: Ви бачите помилки під час скидання. Деякі пристрої некоректно поводяться під час переходів.

Рішення: Якщо помилки корелюють із операціями скидання і потім зупиняються, документуйте це і перевірте вендорські рекомендації. Якщо вони тривають — вважайте це несправністю або компрометацією.

Жарт №1: PCIe-пристрій без IOMMU — це як дати дитині головний ключ від вашої квартири. Вони «допомагатимуть» творчо.

Швидкий план діагностики

Коли щось пахне недобре — помилки VFIO, випадкова корупція, несподівані просідання продуктивності — не шпурляйтесь у довгі розкопки. Використайте
послідовність, яка швидко звузить домен несправності. Ось план, який я тримаю в голові.

Перш за все: IOMMU справді увімкнено і застосовується?

Перевірте /proc/cmdline на наявність intel_iommu=on або amd_iommu=on, і слідкуйте за ризиковими значеннями на кшталт iommu=pt.
Перевірте dmesg на «IOMMU enabled» і «Interrupt remapping enabled.»
Перевірте, що /sys/kernel/iommu_groups/ існує.

Якщо цього бракує — зупиніться. Виправте прошивку + параметри ядра. Решта — шум.

Друге: чи реальна ізоляція пристрою (групи та топологія)?

Перелічіть групи IOMMU і переконайтеся, що ваш цільовий пристрій не згрупований з не пов’язаними пристроями.
Перевірте, чи ACS присутній/працює; якщо ні — не прикидатися, що у вас є ізоляція.

Якщо групування надто грубе — ваш план passthrough фактично ділиться межами довіри.

Третє: чи є помилки IOMMU або збої мапінгу?

Шукайте в логах DMAR/AMD-Vi помилки.
Якщо є помилки: ідентифікуйте пристрій за BDF, перевірте версії драйверів та firmware, корелюйте з скиданнями і піками навантаження.

Часті помилки — не «норма». Це або баг, або неправильна конфігурація, або пристрій, який слід вивести з експлуатації.

Четверте: якщо скарга — продуктивність, виміряйте реальну точку тиску

Перевірте, чи використовуєте hugepages там, де треба.
Підтвердьте DMA mask пристрою (обмеження 32-біт спричиняють bounce buffering).
Перевірте налаштування строгості IOMMU і розгляньте цілеспрямоване тонке налаштування замість глобального passthrough.

Поширені помилки: симптом → корінна причина → виправлення

Ось шаблони, які я бачу постійно, включно в вже «дорослих» середовищах. Більшість можна уникнути, якщо розглядати IOMMU як частину базової конфігурації, а не спеціальний проект.

1) VFIO каже «No IOMMU detected»

Симптом: passthrough VM не запускається; логи скаржаться на відсутню підтримку IOMMU.

Корінна причина: VT-d/AMD-Vi вимкнені в BIOS/UEFI, або параметри завантаження ядра відсутні/неправильні.

Виправлення: Увімкніть VT-d/AMD-Vi у прошивці; додайте intel_iommu=on або amd_iommu=on; перевірте через dmesg, що воно ініціалізувалось.

2) Passthrough працює, але ізоляція фіктивна

Симптом: Ви можете призначити пристрій, але він ділить IOMMU групу з компонентами чіпсету або іншими пристроями.

Корінна причина: Топологія PCIe не підтримує ізоляцію (відсутній ACS або спільні downstream-порти).

Виправлення: Використайте інші слоти, додайте PCIe-комутатори з підтримкою ACS або змініть платформу. Не розгортайте ACS override hacks у продакшні як «безпеку».

3) Випадкова корупція пам’яті під інтенсивним I/O

Симптом: Паніки ядра, корупція алокатора, дивні краші, що нагадують погану RAM.

Корінна причина: IOMMU у режимі passthrough/identity ховає баги DMA; пристрій записує за межі.

Виправлення: Увімкніть строгий IOMMU; оновіть драйвер/firmware; зменшіть агресивні налаштування (глибина черги, скидання під час штормів).

4) Система зависає або пристрої зникають при увімкненні IOMMU

Симптом: Система стає нестабільною після увімкнення IOMMU; деякі пристрої не ініціалізуються.

Корінна причина: Баги в прошивці, старі ядра або пристрої, що розраховують на identity-mapping.

Виправлення: Оновіть BIOS/UEFI; оновіть ядро; розгляньте механізми виведення окремих пристроїв із сумісністю замість глобального вимкнення IOMMU. Якщо пристрій не може співіснувати з IOMMU — поставте під сумнів його придатність.

5) «Ми увімкнули IOMMU, тому Thunderbolt безпечний»

Симптом: Огляд безпеки пропускає ризик Thunderbolt без перевірки політики авторизації ОС.

Корінна причина: Плутання ізоляції DMA з авторизацією пристрою. IOMMU обмежує пам’ять, але не вирішує, хто підключається до шини.

Виправлення: Запровадьте політику авторизації Thunderbolt та вимикайте зовнішні PCIe-подібні порти, якщо вони не потрібні; і все одно тримайте IOMMU увімкненим.

6) Регрес продуктивності звинувачує IOMMU без доказів

Симптом: Пропускна здатність впала; хтось пропонує iommu=pt або вимкнути IOMMU.

Корінна причина: Неміряний вузький горлечко: дрібні сторінки мапінгу, промахи IOTLB, 32-бітні DMA mask-и, або неоптимальні розміри черг.

Виправлення: Спочатку виміряйте; використайте hugepages де доречно; тонко налаштуйте по пристрою; зберігайте примусове застосування для решти системи.

Жарт №2: Вимкнути IOMMU, щоб «підвищити продуктивність» — це як забрати гальма, щоб «зменшити вагу». Працює доти, доки не перестає.

Чек-листи / покроковий план

Чек-лист базового твердого налаштування (флот / датацентр)

Прошивка: Увімкніть VT-d (Intel) або AMD-Vi (AMD). Увімкніть перенаправлення переривань, якщо воно окремо вимикається.
Командна лінія ядра: Встановіть intel_iommu=on або amd_iommu=on. Уникайте глобального iommu=pt, якщо у вас немає списку винятків і обґрунтування.
Верифікація: Забезпечте перевірку під час завантаження: dmesg містить «IOMMU enabled» і «Interrupt remapping enabled».
Інвентар: Збирайте карти IOMMU груп для кожного апаратного SKU. Зберігайте їх як частину знань платформи.
Карантин: Хости без увімкненого IOMMU не виконують робочі навантаження, що потребують passthrough, SR-IOV або ізоляції пам’яті високої довіри.
Логування: Сповіщайте про повторювані помилки IOMMU, а не про поодинокий шум. Повторення — запах реальної проблеми.

Чек-лист для безпечної робочої станції (Thunderbolt / доки / eGPU)

Увімкніть IOMMU в прошивці і підтвердіть через логи.
Блокуйте зовнішні PCIe-подібні порти під час подорожей або в недружніх середовищах.
Використовуйте політики авторизації пристроїв для Thunderbolt; не довіряйте новим периферіям автоматично.
Припускайте, що стани сну/гібернації можуть змінити ландшафт загроз. Перевірте свою позицію через suspend/resume.
Якщо ви працюєте з секретами (ключі, облікові дані), розгляньте апаратне шифрування пам’яті, якщо доступне — але не замінюйте ним IOMMU.

Покроковий план для віртуалізації / VFIO (зробіть правильно)

Доведіть, що IOMMU увімкнено: перевірте /proc/cmdline і dmesg.
Спрямуйте IOMMU групи: переконайтеся, що цільовий пристрій у чистій групі, яку ви можете цілком передати.
Прив’яжіть пристрій до vfio-pci: підтвердіть через lspci -nnk.
Запустіть VM: слідкуйте через journalctl -k -f за помилками VFIO та IOMMU.
Перевірте поведінку під навантаженням: запустіть стрес I/O; слідкуйте за DMAR/AMD-Vi помилками.
Вирішіть рівень строгості: тримайте strict для безпеки й коректності; послаблюйте лише з виміряними перевагами та компенсуючими контролями.

FAQ

1) Якщо в мене є повне шифрування дисків, навіщо хвилюватися DMA-атаками?

Шифрування дисків захищає дані у стані спокою. DMA-атаки націлені на дані в RAM: розшифровані блоки диска в кеші, сесійні ключі,
облікові дані, структури ядра. Якщо система працює — RAM це приз.

2) Чи сповільнює ввімкнення IOMMU систему?

Може, залежно від навантаження і пристрою. Для багатьох загальних навантажень накладні витрати малі. Для NIC-ів з високою пропускною здатністю або спеціалізованих акселераторів ви можете побачити вимірні витрати, якщо мапінги часто змінюються або використовуються дрібні сторінки. Вимірюйте перед панікою і налаштовуйте перед вимкненням.

3) У чому різниця між VT-x/AMD-V та VT-d/AMD-Vi?

VT-x/AMD-V — це розширення віртуалізації CPU (ефективне виконання коду гостя). VT-d/AMD-Vi — це розширення вводу/виводу (утримання DMA пристроїв і безпечне призначення пристроїв). Часто потрібні обидва, але це різні перемикачі.

4) Чи безпечний «iommu=pt»?

Це компроміс. Часто означає, що пристрої за замовчуванням отримують identity-mapping, що може зменшити накладні витрати, але також зменшити ізоляцію для пристроїв, що не використовують DMA API контрольовано. На хостах, чутливих до безпеки, віддавайте перевагу строгому/за замовчуванням режиму і використовуйте passthrough лише там, де це обґрунтовано.

5) Що таке IOMMU групи і чому вони важливі?

Групи представляють найменший набір пристроїв, які можна ізолювати один від одного на основі апаратної маршрутизації та ACS. Якщо два пристрої у одній групі, вважайте, що їх не можна безпечно розділити для passthrough. Ігноруючи це, ви будуєте межу безпеки на основі надії.

6) Чи може зловмисний PCIe-пристрій обійти увімкнений IOMMU?

Не в прямому сенсі «DMA куди завгодно», за умови правильного апаратного забезпечення і конфігурації. Але ви все ще можете програти, якщо:
ви змепили занадто багато пам’яті під пристрій, помилка прошивки платформи підриває ізоляцію або нападник використовує дозволені буфери та помилки в логіці вищого рівня. IOMMU зменшує зону ураження; він не замінює дисципліну дизайну.

7) Чи потрібне перенаправлення переривань теж?

Так, коли доступно. DMA — очевидний ризик, але переривання — це ще один канал, через який пристрої можуть впливати на систему.
Interrupt remapping допомагає запобігти пристроям спрямовувати переривання у несподівані вектори. Це частково безпека, частково стабільність.

8) Чому я бачу помилки IOMMU під час скидання пристрою?

Деякі пристрої виконують DMA-подібні транзакції або «залишкові» записи під час переходу скидання. Строгий IOMMU може їх зафіксувати.
Якщо це рідко і щільно корелює зі скиданням, це може бути відомою особливістю. Якщо повторюється під навантаженням — вважайте це багом або некоректною конфігурацією і ескалуйте.

9) Чи безпечний SR-IOV без IOMMU?

Не робіть цього. SR-IOV відкриває віртуальні функції, що можуть DMA. IOMMU — частина моделі безпеки, яка тримає орендарів від доступу один до одного і до хоста.

10) Як це стосується функцій шифрування пам’яті?

Шифрування пам’яті (залежно від платформи) може зменшити цінність вкраденого вмісту RAM в деяких сценаріях, але DMA все ще може використовуватись для корупції пам’яті, і шифрування може не покривати всі шляхи DMA або буфери, видимі пристроям, так, як ви припускаєте.
Тримайте IOMMU як базову лінію незалежно від шифрування.

Наступні кроки, які ви можете зробити цього тижня

Вам не потрібна лабораторія, бюджетна нарада чи тримісячна ініціатива безпеки, щоб покращити позицію щодо DMA. Потрібні кілька нудних перевірок і готовність їх застосовувати.

Виберіть три репрезентативні машини (сервер, робоча станція, хост для віртуалізації) і виконайте практичні завдання вище. Збережіть виводи.
Стандартизуйте налаштування прошивки для VT-d/AMD-Vi і перенаправлення переривань. Відхилення вважайте несумісністю.
Впровадьте контроль завантажувального логу: якщо ядро не зазначає IOMMU і перенаправлення переривань як увімкнені, хост не запускає чутливі навантаження.
Зробіть інвентар IOMMU груп для кожної моделі обладнання перед закупівлею. Якщо не можете ізолювати те, що потрібно — ви купуєте майбутні проблеми.
Визначте строгість проти passthrough усвідомлено. За замовчуванням — strict. Допускайте винятки по пристрою лише з виміряною потребою та написаною моделлю загроз.
Сповіщайте про повторювані помилки IOMMU і ставтеся до них, як до повторюваних помилок ECC: система каже вам, що щось не в порядку.

Якщо ви запам’ятаєте одне оперативне правило: не довіряйте контролю безпеки, який не можете перевірити командою і рядком логу.
DMA — занадто потужна річ для конфігурацій, основаних на відчуттях.