Ризики Thunderbolt та зовнішнього PCIe: чи потрібен IOMMU на настільних комп’ютерах?

Справжнє питання: чи може зовнішній пристрій стати майстром шини?

«Чи потрібен IOMMU на настільних ПК?» — це не те питання, з якого варто починати. Правильне питання:
Чи може те, що ви під’єднаєте, отримати доступ до пам’яті через DMA, прямо або через ланцюжок «допоміжних» контролерів?

Thunderbolt фактично — це зовнішній PCIe з гарним відділом маркетингу. Зовнішній PCIe означає зовнішні пристрої, які можуть робити те, що й внутрішні PCIe-карти:
запитувати читання/запис пам’яті через DMA. Якщо ви дозволяєте недовіреному пристрою робити DMA у вашу оперативну пам’ять, ваша ОС не має права голосу. Не ваш антивірус. Не екран входу в систему. Не повне шифрування диска після запуску машини.

Це не параноя. Це архітектура. PCIe-пристрої можуть бути майстрами шини. DMA — це спосіб роботи високошвидкісних пристроїв.
Безпека вимагає, щоб DMA був обмежений IOMMU або заблокований суворою політикою до завантаження, яка ніколи не дозволяє недовіреним пристроям на шині.

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

Що таке Thunderbolt насправді (і чому це нервує фахівців із безпеки)

Thunderbolt — це протокол тунелювання. Через один фізичний кабель він може передавати PCIe і DisplayPort, плюс USB та живлення в епоху «USB-C».
Важливою є частина PCIe. Якщо ви тунелюєте PCIe, ви тунелюєте й привілеї, що дає PCIe.

Сучасні контролери Thunderbolt і стек ОС намагаються зробити це безпечнішим. Існують рівні безпеки, авторизація пристроїв і підтримка перенесення DMA (DMA remapping).
Але це все ще система систем: політика BIOS/UEFI, мікропрограма контролера, налаштування ядра ОС і поведінка драйверів повинні узгодитися. Хоч щось із цього може непомітно послабити вашу позицію.

Практична інтерпретація:

• Якщо у вашому настільному ПК є Thunderbolt і ви підключаєте доки/eGPU/зберігання: слід розглядати IOMMU + налаштування безпеки Thunderbolt як обов’язкову гігієну, а не «лише для серверів».
• Якщо ви ніколи не використовуєте Thunderbolt або можете його вимкнути: відключення в прошивці часто є найчистішим способом зменшити ризик.
• Якщо у вашій моделі загроз важливий фізичний доступ недовірених осіб: вам потрібні обмеження Thunderbolt до завантаження та захист DMA на рівні ОС. Також варто подумати про стани сну (про це далі).

Жарт №1: Thunderbolt — це як дати ноутбуку бічні двері в PCIe-фабрику — бо що ж може піти не так із бічними дверима, які відкриваються кабелем?

IOMMU простими словами: що захищає, а що — ні

IOMMU (Intel VT-d, AMD-Vi) — це для DMA те саме, що MMU для доступу CPU до пам’яті: шар трансляції й дозволів.
Він може обмежувати, які області фізичної пам’яті пристрій може бачити. Правильно налаштований, кожному пристрою (або групі пристроїв) дається «пісочниця» для DMA.

Що насправді дає IOMMU

• Ізоляція DMA: пристрій не може читати/записувати довільну RAM, якщо на це немає відображення.
• Утримання некоректних пристроїв: пристрій, що робить некоректний DMA, призведе до помилки замість безшумного пошкодження пам’яті.
• Основа для безпечного hotplug: Thunderbolt — це hotplug. Hotplug без обмеження DMA — фактично «підключай і молись».
• Віртуалізація і passthrough: якщо ви використовуєте KVM/QEMU, PCI passthrough, VFIO або сучасні контейнерні робочі процеси з GPU, вам вже потрібно правильно налаштований IOMMU.

Чого IOMMU не вирішує сам по собі

• DMA до завантаження на системах, які його дозволяють: якщо прошивка дозволяє пристрою робити DMA до того, як ОС налаштує перенесення, це вікно вразливості.
• Зловмисні пристрої всередині дозволених відображень: якщо ви авторизували Thunderbolt-пристрій і ОС відобразила йому широку область пам’яті, пристрій все ще може завдати шкоди в межах цього відображення.
• Погана політика прошивки: якщо налаштування BIOS/UEFI є занадто ліберальними, ви можете постраждати ще до того, як ОС отримає шанс.
• Всі проблеми надійності: обриви лінку, проблеми з живленням, погані кабелі, ретаймери та баги мікропрограми контролера не втримаються вашою IOMMU-філософією.

Є корисна ментальна модель: IOMMU необхідний, але недостатній.
Вам варто його увімкнути, бо це єдиний реальний апаратний механізм для обмеження DMA, але все одно потрібна політика: які пристрої довірені, коли і за яких умов.

Цитата, бо вона пасує тут: Сподіватися — це не стратегія. (парафраз ідеї, що часто звучить у інженерних/операційних колах)

Моделі загроз для настільних ПК, що справді мають значення

Більшість порад в Інтернеті для десктопів передбачає або (a) ви геймер з eGPU, або (b) ви користувач ноутбука, який хвилюється про атаку «зла господиня» (evil maid).
Виробничі настільні ПК розташовані посередині: вони іноді доступні фізично, і в них постійно зберігаються важливі облікові дані.

Модель загроз A: «Офісна реальність» фізичного доступу

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

Модель загроз B: доки та перехідники з елементами ланцюжка постачання

Док спочатку «лише док», поки він не надійде з прошивкою, яка робить щось несподіване, або поки дешевий перехідник насправді не виявиться маленьким комп’ютером.
Вам навіть не потрібно зловмисне наміри; неправильно реалізований пристрій все одно може зіпсувати вам день, посилаючи потоки PCIe-помилок.

Модель загроз C: надійність і цілісність даних

Інженерам зі зберігання даних важливі нудні режими відмов: корупція, скидання шин, kernel panic та мовчазне зниження швидкості до USB2 через поганий кабель.
Зовнішній PCIe швидкий — і крихкий. IOMMU може запобігти деяким категоріям корупції, але він також додає складності, яка може проявитися як «чому мій пристрій зникає тільки коли я вмикаю VT-d?»

Отже, чи потрібен IOMMU на настільних ПК?

Якщо у вашому настільному ПК є Thunderbolt і ви ним користуєтеся, увімкніть IOMMU. Якщо у вас є Thunderbolt і ви його не використовуєте, вимкніть Thunderbolt.
Якщо ви не можете його вимкнути, увімкніть IOMMU і встановіть сувору безпеку Thunderbolt.

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

Факти та історичний контекст, які варто знати

1. Thunderbolt починався як «Light Peak», спочатку уявлявся як оптичний інтерконект, поки мідь не перемогла в ціні та споживанні енергії.
2. Thunderbolt тунелює PCIe, тому eGPU та зовнішні NVMe-корпуси можуть відчуватися «внутрішньо-швидкими», коли все працює коректно.
3. Атаки через DMA виникли ще до Thunderbolt: FireWire (IEEE 1394) відкривав подібні проблеми, бо дозволяв схожі патерни доступу до пам’яті в деяких реалізаціях.
4. Дослідження «Thunderclap» (середина 2010-х) підкреслили реальні шляхи атак через DMA проти Thunderbolt на поширених ОС, що змусило виробників покращити захисти.
5. Існують рівні безпеки Thunderbolt (часто описуються як SL0–SL3), від «без безпеки» до режимів, що вимагають авторизації і обмежують поведінку до завантаження.
6. Kernel DMA Protection стала важливою функцією Windows у відповідь на ризики зовнішнього DMA; вона залежить від підтримки апаратури та прошивки.
7. Linux інтегрував авторизацію Thunderbolt через підсистему thunderbolt і sysfs-контролі; багато дистрибутивів тепер за замовчуванням використовують безпечніші режими «авторизації користувачем», якщо це підтримується.
8. USB4 успадковує багато моделі Thunderbolt; конектор може позначатися як USB-C, але безпека залежить від протоколів, узгоджених під час з’єднання.
9. Групи IOMMU відображають апаратну топологію, а не вподобання: деякі материнські плати об’єднують кілька пристроїв в одну групу, що обмежує ізоляцію і безпечний passthrough.

Три корпоративні історії з поля

1) Інцидент через неправильне припущення: «Це ж просто док для монітора»

Середня інженерна організація розгорнула однакові док-станції Thunderbolt, щоб пришвидшити підключення на робочих місцях. Припущення на папері було слушним:
доки — це периферія, а периферія — невисокий ризик. Чек-лист розгортання зосереджувався на відображенні і стабільності Ethernet, а не на DMA.

Через кілька тижнів помітили дивну картину: розробники час від часу скаржилися, що запити облікових даних поводяться «неправильно», а кілька машин викидали журнали ядра,
заповнені PCIe AER помилками одразу перед крахом. Безпеку викликали лише після того, як під час судово-технічного аналізу виявили ознаки зчитування пам’яті.
Ніхто не міг довести зловмисність, але й ніхто не міг довести невинність — а це означає поганий день в операціях.

Корінь проблеми був у тому, що частина машин поставлялася з лояльними налаштуваннями Thunderbolt до завантаження, а IOMMU був вимкнений у BIOS на деяких настільних ПК
через старий внутрішній міф «VT-d знижує продуктивність». Сам док, ймовірно, не був зброєю; середовище було надто довірливим.
Коли ви даєте тунелюванню PCIe вільний хід, ви ставите на карту весь флот залежно від кожного оновлення прошивки дока.

Виправлення було не гламурним: стандартизувати налаштування BIOS (увімкнути VT-d/AMD-Vi, встановити безпеку Thunderbolt в режим авторизації, де можливо — відключити Thunderbolt до завантаження),
впровадити політики ОС і додати аудит подій підключення в моніторинг кінцевих точок. Доки не стали швидшими. Інциденти — припинилися.

2) Оптимізація, яка обернулася проти: «Вимкніть IOMMU заради нижчої затримки»

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

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

Курящим доказом стало порівняння дампів і журналів ядра між машинами: корупції групувалися навколо подій hotplug PCIe і скидів лінку.
Без IOMMU одна проблемна ревізія прошивки корпусу могла DMA-нути в місця, де не слід, під час шляхів відновлення після помилок.
Це не була гарантована корупція; це була «можлива корупція». Саме так ви опиняєтеся на нарадах з юридичним відділом.

Повернення IOMMU не вирішило миттєво кожну проблему з продуктивністю, але зробило систему безпечнішою: помилки пристрою ставали помилками IOMMU і відновлюваними помилками I/O,
а не безшумною корупцією пам’яті. Потім вони вже правильно шукали реальні проблеми з затримкою: призначення IRQ, налаштування живлення і версії драйверів. «Оптимізація» виявилася просто зняттям запобіжників.

3) Сумно, але правильна практика, що врятувала ситуацію: контрольована авторизація + інвентаризація

Команда фінансових послуг працювала з робочими станціями розробників, які оперували продукційними обліковими даними. Вони не були ідеальні, але дисципліновані.
Thunderbolt був дозволений, бо робочі місця потребували багатомоніторності та швидких робочих процесів образів, але кожен пристрій мав бути авторизований.

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

Одного дня підрядник підключив невідомий док у лабораторній зоні. Машина нічого не змонтувала і не впала; вона просто зафіксувала новий Thunderbolt-пристрій як
присутній-але-неавторизований. SOC отримав сповіщення з телеметрії кінцевої точки, що «новий зовнішній PCIe-пристрій намагався перерахуватися».
Реакція була швидкою й сумною: конфіскувати док, перевстановити образ машини з пересторогами і переглянути відеозаписи. Ніякого оповідання про злам — жодного драматизму.

Ось як виглядає «нудно», коли це працює: потенційно неприємна подія перетворюється на тикет і чек-лист. Ніхто не отримує бойову історію. Це і є мета.

Швидкий playbook діагностики: «вузьке місце» vs помилка vs межа довіри

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

Перш за все: доведіть, з яким лінком ви насправді узгодились

• Чи справді пристрій на Thunderbolt/PCIe, чи він упав у USB?
• Чи затримався він на низькій швидкості через кабель/ретаймер?
• Чи є петля повторного тренування PCIe лінку?

Друге: перевірте стан IOMMU/DMAR/IVRS і помилки

• Чи IOMMU увімкнено і активне?
• Чи є помилки IOMMU, що вказують на заблокований DMA (добре для безпеки, погано для сумісності пристроїв)?
• Чи пристрої згруповані так, що це перешкоджає ізоляції?

Третє: перевірте стан безпеки/авторизації Thunderbolt

• Чи пристрій авторизовано?
• Чи система у дозволяючому рівні безпеки?
• Чи поведінка до завантаження дозволяє надто ранню енумерацію?

Четверте: перевірте живлення та прошивку

• Чи не нестача живлення порту для корпусу з живленням від шини?
• Чи є відома погана ревізія прошивки контролера?
• Чи ви використовуєте «таємний кабель з конференції»?

Жарт №2: Найшвидший спосіб відлагодити Thunderbolt — замінити кабель; другий за швидкістю спосіб — прикинутися, що ви замінили кабель, і витратити дві години даремно.

Практичні завдання: перевірити, зміцнити та усунути неполадки (з командами)

Команди нижче орієнтовані на Linux, бо Linux показує правду у відкритому вигляді. Windows має еквіваленти (Device Manager, PowerShell, event logs),
але робочий процес діагностики однаковий: перевірити підтримку апаратури, політику прошивки, застосування в ОС, а потім протестувати на реальному пристрої.

Завдання 1: Перевірити, чи IOMMU увімкнено в ядрі (dmesg)

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|AMD-Vi|IVRS' | head -n 30
[    0.000000] DMAR: IOMMU enabled
[    0.000000] DMAR: Host address width 39
[    0.000000] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.000000] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c90780106f0462 ecap f020de
[    0.000000] DMAR: RMRR base: 0x0000000009f00000 end: 0x0000000009ffffff

Що це означає: «IOMMU enabled» вказує, що Intel VT-d активний. На AMD ви побачите рядки AMD-Vi/IVRS.
RMRR-області (зарезервована пам’ять) можуть натякати, що деякі пристрої потребують identity-mapping (може ускладнювати ізоляцію).
Рішення: Якщо ви нічого не бачите або бачите «IOMMU disabled», виправте BIOS/UEFI та параметри завантаження ядра перед подальшими діями.

Завдання 2: Підтвердити розширення віртуалізації CPU та можливість IOMMU

cr0x@server:~$ lscpu | egrep -i 'Virtualization|Vendor ID|Model name'
Vendor ID:                       GenuineIntel
Model name:                      Intel(R) Core(TM) i9-12900K
Virtualization:                  VT-x

Що це означає: VT-x — це підтримка віртуалізації CPU; це не VT-d. Але якщо VT-x є на сучасній платформі, VT-d часто теж присутнє.
Рішення: Тут не зупиняйтеся. Все ще потрібно перевірити VT-d/AMD-Vi у прошивці та dmesg.

Завдання 3: Перевірити рядок команд ядра на наявність IOMMU та режим passthrough

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

Що це означає: intel_iommu=on примусово вмикає VT-d; amd_iommu=on — еквівалент для AMD.
iommu=pt увімктає passthrough-відображення для продуктивності в деяких випадках, але це може зменшити переваги ізоляції для пристроїв, які не ремапляться явно.
Рішення: Для настільних ПК з Thunderbolt та безпековою позицією краще обирати повне ремапування (не використовувати iommu=pt), якщо немає виміряних причин.

Завдання 4: Перелічити пристрої Thunderbolt і їхній стан авторизації

cr0x@server:~$ boltctl
 ● Dell TB16 Dock
   ├─ type:          peripheral
   ├─ name:          Dell Thunderbolt Dock
   ├─ vendor:        Dell
   ├─ uuid:          2c1b8b50-8d41-4e1e-9f5a-5c6b0b2a1a1d
   ├─ status:        authorized
   ├─ stored:        yes
   └─ policy:        auto

Що це означає: «authorized» означає, що ОС дозволила його. «stored: yes» означає, що авторизація збережена.
Рішення: У середовищі з підвищеним ризиком встановіть політику на ручну авторизацію і зберігайте мінімум авторизованих пристроїв. Якщо з’являються невідомі пристрої, ставте це як інцидент, а не цікавинку.

Завдання 5: Переглянути рівень безпеки Thunderbolt, який показує ядро

cr0x@server:~$ cat /sys/bus/thunderbolt/devices/domain0/security
user

Що це означає: Поширені значення: none, user, іноді secure.
«user» зазвичай вимагає авторизації нових пристроїв.
Рішення: Якщо там none на системі, що використовується у спільних просторах, змініть налаштування BIOS/UEFI Thunderbolt і/або політику ОС. «none» — це «підключив і володію».

Завдання 6: Визначити, чи корпус «Thunderbolt» насправді використовує режим USB-зберігання

cr0x@server:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=uas, 10000M

Що це означає: Якщо пристрій видно через USB з UAS, можливо, ви використовуєте USB 3.x, а не тунелювання PCIe/NVMe.
Рішення: Якщо продуктивність низька, перевірте, чи погодилися Thunderbolt чи USB. Деякі корпуси підтримують обидва режими і мовчки відкатуються.

Завдання 7: Перелічити PCIe-пристрої і знайти контролери Thunderbolt та мости

cr0x@server:~$ lspci -nn | egrep -i 'thunderbolt|usb4|dsl|jhl|maple|bridge'
00:07.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [8086:1136]
00:0d.2 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [8086:1137]

Що це означає: Ви бачите інтерфейс хоста Thunderbolt (NHI) і мости, що представляють тунельовану PCIe-ієрархію.
Рішення: Якщо ваш порт «Thunderbolt» взагалі не з’являється, підозрюйте вимкнення в BIOS, відсутні драйвери або платформу без фактичного Thunderbolt/USB4 тунелювання.

Завдання 8: Перевірити швидкість і ширину PCIe-лінку для пристрою (реальна продуктивність)

cr0x@server:~$ sudo lspci -s 00:07.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #9, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 8GT/s (downgraded), Width x2 (downgraded)

Що це означає: Пристрій здатний на 16GT/s x4, але зараз працює на 8GT/s x2. Це зменшення пропускної здатності.
Рішення: Перед тим як звинувачувати IOMMU, виправте фізичний рівень: кабель, док, порт, прошивка і живлення. Пониження лінку зазвичай — проблема шляху сигналу.

Завдання 9: Шукати спам PCIe Advanced Error Reporting (AER) — індикатор проблем з надійністю

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'AER|pcieport|DPC|fatal|Surprise Down' | tail -n 30
pcieport 0000:00:07.0: AER: Corrected error received: 0000:00:07.0
pcieport 0000:00:07.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
pcieport 0000:00:07.0: AER:   device [8086:1136] error status/mask=00001000/00002000
pcieport 0000:00:07.0: AER:    [12] Timeout

Що це означає: Виправлені помилки можуть бути пережиті, але вказують на проблеми з цілісністю сигналу. «Surprise Down» часто позначає відключення або подію живлення.
Рішення: Якщо AER-помилки корелюють із зависаннями, вважайте док/кабель/контролер підозрілими. Спочатку замініть кабель, потім оновіть прошивку і потестуйте інший док.

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

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group ${g##*/}"; lspci -nns $(basename -a $g/devices/*); echo; done | head -n 40
IOMMU Group 0
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4660]

IOMMU Group 7
00:07.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [8086:1136]
00:0d.2 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [8086:1137]

Що це означає: Пристрої в одній IOMMU-групі не можна ізолювати один від одного. Деякі плати з’єднують половину чіпсету разом, що є проблемою.
Рішення: Для VFIO/passthrough вам може знадобитись підтримка ACS або інший апарат. Для безпеки великі групи означають ширшу зону ураження, якщо пристрій відображено.

Завдання 11: Перевірити наявність IOMMU-помилок (блоковані спроби DMA)

cr0x@server:~$ sudo dmesg | egrep -i 'iommu fault|DMAR:.*fault|AMD-Vi:.*Event' | tail -n 20
DMAR: [DMA Write NO_PASID] Request device [00:0d.2] fault addr 0x0000000f7c0000 [fault reason 0x05] PTE Write access is not set

Що це означає: Пристрій намагався робити DMA до адреси, яка не дозволена. Це може бути некоректний драйвер, неправильно налаштована політика ремапування або ворожий пристрій.
Рішення: Якщо помилки виникають під час нормального використання довірених пристроїв, оновіть прошивку/драйвери і перегляньте параметри ядра. Якщо помилки з’явилися після підключення невідомого обладнання — ескалюйте.

Завдання 12: Переконатися, що hotplug Thunderbolt керується авторизацією (вид udev)

cr0x@server:~$ udevadm monitor --kernel --property
KERNEL[12345.678901] add      /devices/pci0000:00/0000:00:07.0/thunderbolt/domain0/0-0 (thunderbolt)
ACTION=add
SUBSYSTEM=thunderbolt
DEVPATH=/devices/pci0000:00/0000:00:07.0/thunderbolt/domain0/0-0
DEVNAME=/dev/thunderbolt0

Що це означає: Ви можете бачити події енумерації в реальному часі. Поєднайте це з boltctl, щоб спостерігати, чи з’являються нові пристрої як неавторизовані.
Рішення: Якщо пристрої з’являються повністю функціональними без авторизації в середовищі з високою безпекою, ваш рівень безпеки Thunderbolt занадто дозволячий.

Завдання 13: Підтвердити шлях пристрою NVMe (Thunderbolt PCIe проти USB mass storage)

cr0x@server:~$ lsblk -o NAME,TRAN,MODEL,SIZE,TYPE,MOUNTPOINT
NAME        TRAN   MODEL                 SIZE TYPE MOUNTPOINT
nvme0n1     pcie   Samsung SSD 980 PRO  931G disk
nvme1n1     pcie   External NVMe        1863G disk /mnt/ext
sda         usb    USB DISK             931G disk /mnt/usb

Що це означає: TRAN=pcie вказує, що ядро бачить його як NVMe/PCIe-пристрій (типово для справжніх Thunderbolt NVMe-корпусів).
TRAN=usb означає USB-зберігання.
Рішення: Якщо ви очікували PCIe, а отримали USB, перевірте узгодження кабелю/порту і режим корпусу.

Завдання 14: Виміряти реальну пропускну здатність і виявити тротлінг (перевірка сховища)

cr0x@server:~$ sudo fio --name=extseq --filename=/mnt/ext/testfile --size=4G --direct=1 --rw=write --bs=1M --iodepth=16 --numjobs=1 --runtime=30 --time_based
extseq: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=16
fio-3.36
...
WRITE: bw=1850MiB/s (1940MB/s), 1850MiB/s-1850MiB/s (1940MB/s-1940MB/s), io=55.3GiB (59.4GB), run=30666-30666msec

Що це означає: Це здоровий показник «швидкого зовнішнього NVMe» для багатьох конфігурацій Thunderbolt. Якщо ви бачите 300–500MB/s, можливо, ви в USB-режимі або лінк понижено.
Рішення: Використовуйте результати fio разом зі статусом лінку (Завдання 8), щоб вирішити, чи це проблема з сховищем, чи проблема узгодження з’єднання.

Завдання 15: Перевірити стани управління живленням, що спричиняють відключення пристроїв

cr0x@server:~$ cat /sys/module/pcie_aspm/parameters/policy
powersave

Що це означає: Агресивний ASPM може викликати проблеми лінку на маргінальному апаратному шляху.
Рішення: Якщо ви маєте сплески лінку/AER timeout, тимчасово спробуйте pcie_aspm=off. Якщо це виправляє стабільність, ви знайшли проблему сигналу/енергетичного запасу — тоді вибирайте між стабільністю та енергозбереженням.

Завдання 16: Перевірити еквівалентну політику для Windows (з боку Linux: перевірити, чи прошивка відкриває захист DMA)

cr0x@server:~$ sudo mokutil --sb-state
SecureBoot enabled

Що це означає: Secure Boot — це не IOMMU, але частина «ланцюга довіри від прошивки до ОС». На змішаних парках машини з вимкненим Secure Boot часто також мають інші ліберальні налаштування прошивки.
Рішення: Якщо ви не можете стандартизувати налаштування прошивки, ви будете ганятися за примарами: одна машина поводиться добре, інша — ні, і єдина різниця — тумблер у BIOS, який хтось змінив у 2022 році.

Типові помилки: симптом → корінь проблеми → виправлення

1) «Thunderbolt-зберігання повільне, як SATA»

Симптоми: ~300–550MB/s, велика затримка, непослідовна продуктивність.

Корінь проблеми: Корпус узгодив режим USB (UAS) замість тунелювання PCIe/NVMe, або PCIe-лінк понижено (x1/x2, менший GT/s).

Виправлення: Використайте lsusb -t і lsblk -o TRAN, щоб підтвердити транспорт. Перевірте статус лінку через lspci -vv. Замініть кабель/порт; оновіть прошивку дока/корпусу.

2) «Випадкові зависання при підключенні/відключенні»

Симптоми: Жорсткий лок, чорні екрани, kernel panic, іноді лише під час hotplug.

Корінь проблеми: Шторми AER, баги прошивки контролера або hotplug у поєднанні з агресивним ASPM/керуванням живленням.

Виправлення: Перевірте journalctl -k на наявність AER/DPC повідомлень. Потестуйте відомо-робочий кабель. Тимчасово встановіть pcie_aspm=off. Оновіть BIOS і прошивку контролера Thunderbolt.

3) «Усе зламалося після ввімкнення VT-d/IOMMU»

Симптоми: Док не розпізнається, пристрої зникають, завантаження довшає, дивна поведінка драйверів.

Корінь проблеми: Прошивка має биті DMAR-таблиці, потрібні ядрові обхідні шляхи, або пристрої залежать від identity-mapping, що змінюється під IOMMU.

Виправлення: Спочатку оновіть BIOS. Перегляньте dmesg на предмет DMAR/IOMMU помилок. Акуратно тестуйте параметри ядра (наприклад, примусове вмикання/вимкнення IOMMU для вендора). Якщо конкретний пристрій поводиться некоректно, вважайте його недовіреним і замініть.

4) «Ми налаштували безпеку Thunderbolt, але хтось все одно може підключити будь-який док»

Симптоми: Невідомі пристрої працюють одразу; немає запитів/журналів авторизації.

Корінь проблеми: Рівень безпеки Thunderbolt у BIOS встановлений як none, підтримка до завантаження увімкнена, або політика ОС не застосовується.

Виправлення: Перевірте /sys/bus/thunderbolt/devices/domain0/security і boltctl. Посиліть прошивкову політику: відключіть Thunderbolt до завантаження, вимагайте авторизацію користувача.

5) «eGPU працює, але продуктивність дивна і іноді GPU зникає»

Симптоми: Скиди GPU, тайм-аути драйвера, зниження ширини PCIe, переривчасті відключення під навантаженням.

Корінь проблеми: Нестабільність лінку, проблеми з подачею живлення або насичення контролера Thunderbolt під великим I/O разом з трафіком дисплея.

Виправлення: Перевірте ширину/швидкість лінку через lspci -vv. Перегляньте журнали ядра на наявність AER. Забезпечте достатнє живлення, використовуйте короткі сертифіковані кабелі і уникайте підключення багатьох пристроїв через один порт, якщо вам потрібна передбачувана затримка.

6) «Ми вважаємо, що повне шифрування диска робить DMA неактуальним»

Симптоми: Аргумент політики, а не збій: «ми ж зашифровані, отже безпечні».

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

Виправлення: Увімкніть IOMMU і функції захисту DMA; обмежте авторизацію Thunderbolt; зменшіть вікно впливу станів сну; застосуйте політику блокування екрана й підвищеної безпеки при переході в режим сну.

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

Чек-лист A: Зміцнення настільного ПК, що щоденно використовує доки Thunderbolt

1. Базова налаштування прошивки: увімкніть VT-d/AMD-Vi; увімкніть Secure Boot, якщо ваша організація це підтримує; оновіть BIOS до відомої доброї ревізії.
2. Рівень безпеки Thunderbolt: встановіть режим авторизації користувача (або найсуворіший підтримуваний); де можливо — відключіть Thunderbolt до завантаження.
3. Застосування ОС: на Linux переконайтесь, що безпека Thunderbolt не встановлена в none; використовуйте bolt для керування авторизацією; журналюйте події hotplug.
4. Перевірка IOMMU: підтвердіть у dmesg, що IOMMU увімкнено і що під час звичайного підключення немає безперервного спаму помилок.
5. Інвентар пристроїв: зберігайте та затверджуйте лише корпоративно затверджені доки; видаляйте застарілі авторизації для пристроїв, що більше не в обігу.
6. Тест на надійність: проводьте стрес-тести (fio для сховища, навантаження GPU для eGPU), спостерігаючи за AER-помилками і пониженням лінку.
7. Дисципліна з кабелями: стандартизуйте кабелі; маркуйте їх; уникайте довгих пасивних трас, що межують із запасом сигналу.
8. Хук для реагування на інциденти: розглядайте невідому енумерацію Thunderbolt як сигнал безпеки; не всі сигнали — інциденти, але всі сигнали потребують запису.

Чек-лист B: Якщо вам не потрібен Thunderbolt — позбудьтеся проблеми

1. Вимкніть тунелювання Thunderbolt/USB4 у BIOS/UEFI, якщо платформа це дозволяє.
2. Явно вимкніть підтримку Thunderbolt до завантаження.
3. Фізично заблокуйте порти на системах з високим ризиком (так, серйозно), якщо система розташована у неконтрольованому просторі.
4. Все одно тримайте IOMMU увімкненим, якщо ви віртуалізуєте або дбаєте про ізоляцію внутрішніх пристроїв.

Чек-лист C: Рішення щодо iommu=pt і налаштування продуктивності

1. Почніть із повного ремапування IOMMU (без режиму passthrough).
2. Вимірюйте: час завантаження, пропускну здатність I/O, робочі навантаження, чутливі до затримки.
3. Якщо продуктивність помітно постраждала, випробуйте iommu=pt лише на тестовій машині.
4. Повторно перевірте: помилки IOMMU, поведінку авторизації Thunderbolt і чи відповідає ваша безпекова позиція середовищу.
5. Прийміть рішення: якщо ваші настільні ПК піддаються недовіреному фізичному доступу, не жертвуйте захистом DMA заради невеликих вигод.

FAQ

1) Якщо я на настільному ПК (не ноутбук), чи Thunderbolt все одно є ризиком DMA?

Так. Різниця між десктопом і ноутбуком нічого не змінює стосовно PCIe. Настільні ПК можуть бути навіть більш уразливими, бо вони стоять в офісах, лабораторіях і загальних просторах з легким доступом до портів.

2) Чи увімкнення IOMMU завжди запобігає атакам DMA через Thunderbolt?

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

3) У чому різниця між VT-x і VT-d?

VT-x — це підтримка віртуалізації CPU. VT-d — це IOMMU (DMA remapping). Люди часто плутають їх. Для ізоляції DMA через Thunderbolt вам потрібен VT-d/AMD-Vi.

4) Чи IOMMU погіршить продуктивність на робочій станції?

Зазвичай це не помітно для звичайних десктоп-навантажень. Можуть бути крайові випадки (деякі робочі процеси з дуже низькою затримкою аудіо/відео або баги прошивки).
Вимірюйте перед оптимізацією і не «оптимізуйте», відключаючи засоби безпеки.

5) Я увімкнув VT-d, і мій док став нестабільним. Чи вимкнути VT-d?

Ні — принаймні не як перший крок. Оновіть BIOS і прошивку Thunderbolt, протестуйте з іншим кабелем/доком і перевірте dmesg на помилки IOMMU.
Якщо док працює лише коли захист DMA вимкнено, цей док сам про себе багато розказує.

6) Чи USB-C те саме, що Thunderbolt/USB4?

USB-C — це форма роз’єму. Thunderbolt і USB4 — це протоколи, що можуть працювати через нього. Безпека залежить від того, які протоколи узгоджуються.
Порт USB-C може бути «лише USB» (нижчий ризик DMA) або повноцінним тунелюванням PCIe (вищий ризик DMA).

7) Чи повне шифрування диска захищає від атак Thunderbolt?

Воно захищає дані у стані спокою. Коли ОС працює і розблокована, у RAM містяться секрети. DMA націлюється на RAM. Шифрування необхідне, але недостатнє.

8) Чи стани сну/гібернації змінюють ризик?

Стани сну можуть розширити вікно, коли пристрої залишаються під живленням і можуть взаємодіяти з пам’яттю або шинами несподіваним чином.
Гібернація (повністю вимкнено, пам’ять записана на диск) зазвичай безпечніша для моделі загроз з фізичним доступом — за умови, що шифрування диска надійне і машина дійсно повністю вимкнена.

9) Якщо я використовую лише корпоративні доки, чи можна пропустити авторизацію Thunderbolt?

Можна, але ви обираєте зручність замість контролю. Авторизація дає слід і блокує події «хтось підключив випадковий док».
У корпоративному середовищі це варто ні за якісь незначні незручності.

10) Чи важливі групи IOMMU, якщо я не роблю VFIO passthrough?

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

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

Якщо ви експлуатуєте настільні ПК як важливі системи — тому що вони важливі — ставтеся до Thunderbolt і зовнішнього PCIe як до production-інтерфейсу:
швидкого, потужного і абсолютно здатного зіпсувати вам тиждень.

1. Визначте позицію: якщо вам не потрібен Thunderbolt — вимкніть його у прошивці. Якщо потрібен — увімкніть IOMMU і вимагайте авторизацію.
2. Стандартизуйте прошивку: документуйте налаштування BIOS/UEFI для VT-d/AMD-Vi і безпеки Thunderbolt; впровадьте їх у парку машин.
3. Підтвердіть з доказами: виконайте перевірки dmesg/boltctl/lspci вище і збережіть результати як базову довідку.
4. Виправте фізичний рівень: припиніть відлагодження «випадкових» помилок за допомогою випадкових кабелів. Купуйте відомі хороші кабелі, маркуйте їх та виводьте з експлуатації прокляті екземпляри.
5. Інструментуйте межу: журналюйте додавання пристроїв Thunderbolt і події авторизації. Невідомі пристрої мають автоматично створювати тикет.

Настільні ПК не сервери, але в них зберігаються ключі до вашого королівства. Зовнішній PCIe — це межа привілеїв. Поводьтеся відповідно.