Несигновані драйвери: коли безпека зламала цілком справний апарат

November 11, 2025 • February 3, 2026 • Читання: 4 хв • Views: 0

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

Апаратний засіб у порядку. Кабелі підключені. Індикатори блимають як завжди. І все ж ваш SAN-шлях зник, мережевий інтерфейс пропав,
або вузол з GPU раптом показується як «unknown device». Ласкаво просимо в сучасний інцидент: не диск, що виходить із ладу, а драйвер, який став політично
неприйнятним за одну ніч.

Несигновані (або неправильно підписані) драйвери не просто «не встановлюються». У реальних системах вони дають гучний збій — під час завантаження,
після оновлення, під Secure Boot або тільки на підмножині хостів, які правильно застосовують політики. Результат виглядає як апаратна відмова,
але насправді це відмова довіри. Комп’ютер перестав вірити в пристрій. Він перестав вірити в вас.

Що насправді зламалось: довіра, а не апарат

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

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

Є три широкі категорії болю, пов’язаного з «несигнованими драйверами»:

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

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

Зникнення всіх шляхів до LUN під час завантаження (multipath колапсує, файлові системи переходять у режим лише для читання, бази даних панікують).
Перейменування інтерфейсів або відсутність NIC (bonding руйнується, VRRP падає, кластер втрачає кворум).
Вузли з GPU втрачають прискорення і перетворюються на дорогі обігрівачі.
Інструменти управління RAID/HBA можуть падати так, що приховують реальні проблеми з дисками.

Факти та контекст: як ми сюди потрапили

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

Windows x64 почав активно вимагати підпис драйверів у середині 2000-х. Зміни були поступовими, але напрямок — односторонній: більше контролю, менше винятків.
Secure Boot змінив модель загроз. Після перевірки прошивки й ланцюжка завантаження несигновані модулі ядра стали очевидною спробою обходу.
Stuxnet (2010) використовував підписані драйвери. Реальні сертифікати були зловживані для завантаження шкідливих драйверів ядра; це довело, що підписи потрібні, але недостатні.
Оперативне відкликання сертифікатів стало реальною проблемою. Коли ключ підпису скомпрометовано, вендори відкликають його. Це може зламати старі драйвери, які «вчора були в порядку».
Депрецирування SHA-1 змусило перевипускати підписи. Деякі старі підписи драйверів покладалися на криптоалгоритми, що нині вважаються слабкими; платформи все частіше їх відхиляють.
Windows Hardware Quality Labs (WHQL) формували поведінку вендорів. «Правильний підпис» часто означає проходження екосистемних процесів, а не лише купівлю сертифіката.
У Linux існує підпис модулів, але політика залежить від дистрибутиву і організації. Ядро може перевіряти підписи модулів, але чи робить воно це — залежить від конфігурації, Secure Boot та режимів lockdown.
Оновлення UEFI dbx можуть вивести з довіри раніше надійні компоненти завантаження. Списки відкликаних елементів оновлюються в прошивці; ваш драйвер може бути підписаний, але опорний ключ пізніше занесено в чорний список.
Віртуалізація не усунула проблему; вона її перемістила. VFIO, SR-IOV, vGPU і passthrough залежать від стабільного завантаження драйверів ядра відповідно до політик.

Якщо шукати винуватця, то це не «безпека». Це припущення, що код ядра можна ставити в один ряд з userland‑додатками. Так не працює. Ядро — тонка межа між «сервером» та «абстрактним мистецтвом».

Одна цитата, що варта нотатки поруч з вашим календарем змін:

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

Режими відмов, через які несигновані драйвери здаються випадковими

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

1) Політика активується лише під Secure Boot або в lockdown

Багато середовищ мають «поділ розуму»: деякі хости мають увімкнений Secure Boot (або режим «lockdown»), інші — ні. Драйвер завантажується
на дозволяючих хостах, падає на строгих. Різниця може бути в перемикачі BIOS, варіації золотого образу або в інженері на місці, який
«пофіксив» щось під час візиту в шафу.

2) Оновлення ядра змінює бінарник, тому підпис більше не відповідає

Якщо ви покладаєтесь на DKMS-збирані модулі (типово для NIC, HBA, драйверів GPU, ZFS-on-Linux і різних «продуктивних» надбудов), оновлення
ядра викликає перебудову. Така перебудова також має бути підписана в середовищах із Secure Boot. Якщо ні — модуль просто не завантажиться.

3) Драйвер підписаний, але ланцюжок більше не довіряється

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

4) Вендори постачають кілька пакетів з різним станом підпису

Часто можна побачити «datacenter» пакет і «desktop» пакет, або гілки «legacy» і «modern». Одна підписана атестаційно, інша — тестово, ще одна — підписана вендором, але не прийнята екосистемою.
Встановіть неправильну — і ви працюєте в режимі тимчасової позики.

5) Люди рідко перезавантажують

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

Жарт #1 (короткий, по суті): Драйвери як парашути: відсутність шва ви помічаєте лише тоді, коли вони справді потрібні.

Швидкий план діагностики (перший/другий/третій)

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

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

Чи видно PCI‑пристрій в ОС?
Чи змінився стан Secure Boot/lockdown?
Чи оновлювалося ядро? Чи перебудовувався драйвер?

Другий: доведіть відмову завантаження драйвера й зафіксуйте точну причину

Перегляньте логи ядра на предмет відхилення підпису, «taint» або “Required key not available”.
Перевірте, чи існує модуль, чи співпадає його vermagic і чи він підписаний.
Перевірте коди помилок у Windows Device Manager (особливо Code 52) та стан підпису.

Третій: оберіть між трьома безпечними шляхами відновлення

Зміна політики (тимчасово): відключити примус контролю, щоб відновити сервіс, але розглядати це як контрольований break‑glass.
Заміна драйвера: встановити коректно підписану версію драйвера, що відповідає політиці та збірці ОС.
Виправлення процесу підписування: підписувати DKMS‑модулі (MOK у Linux) або використовувати сертифіковані пакети вендора (WHQL/attestation у Windows).

Помилка — робити всі три одночасно, створювати шум і втрачати причинно‑наслідковий зв’язок. Виберіть гіпотезу, зберіть докази, виконайте одну зміну, перевірте.

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

Нижче — практичні завдання, які можна виконати на реальних системах. Кожне містить: команду, приклад виводу, що означає цей вивід, і рішення, яке ви приймаєте.
Команди розділені між Linux і Windows (через PowerShell, але виконуються з bash‑подібного промпту за допомогою pwsh, де доречно). Використовуйте те, що застосовується до вашого середовища.

Завдання 1 (Linux): підтвердьте стан Secure Boot

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

Значення: система застосовує політику верифікованого завантаження. Несигновані модулі ядра можуть бути заблоковані.

Рішення: якщо ви покладаєтесь на модулі поза ядром (DKMS, драйвери вендора), потрібно забезпечити підписування модулів.

Завдання 2 (Linux): перевірте режим lockdown ядра

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

Значення: lockdown активний (integrity/confidentiality). Це часто супроводжує Secure Boot і може обмежувати завантаження модулів та інтерфейси ядра.

Рішення: вважайте «unsigned module won’t load» очікуваною поведінкою; виправляйте підпис замість боротьби з ядром.

Завдання 3 (Linux): підтвердьте, що PCI‑пристрій виявлений

cr0x@server:~$ lspci -nn | egrep -i 'ethernet|fibre|raid|nvme'
03:00.0 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme BCM57414 [14e4:16d7]
05:00.0 Fibre Channel [0c04]: Emulex Corporation LPe32002-M2 [10df:f0f5]

Значення: перерахування апаратури працює. ОС бачить пристрій на шині.

Рішення: зосередитись на прив’язці/завантаженні драйвера, а не на кабелях чи заміні апаратури.

Завдання 4 (Linux): перевірте, який драйвер прив’язаний (або ні)

cr0x@server:~$ lspci -k -s 05:00.0
05:00.0 Fibre Channel: Emulex Corporation LPe32002-M2
	Subsystem: Emulex Corporation LPe32002-M2
	Kernel driver in use: (none)
	Kernel modules: lpfc

Значення: ядро знає модуль, який може обслуговувати пристрій (lpfc), але він не завантажений/не приєднаний.

Рішення: спробувати завантажити модуль і спостерігати логи на предмет помилок підпису.

Завдання 5 (Linux): спробуйте завантажити модуль і зафіксуйте помилку

cr0x@server:~$ sudo modprobe lpfc
modprobe: ERROR: could not insert 'lpfc': Key was rejected by service

Значення: це проблема підпису/довіри (key rejected). У системах із Secure Boot це часто означає, що модуль не підписано ключем, якому довіряє ядро.

Рішення: не повторюйте без кінця спроби. Перевірте підпис модуля і зареєструйте ключ (MOK) або встановіть підписаний пакет від вендора.

Завдання 6 (Linux): витягніть точний рядок логу ядра

cr0x@server:~$ dmesg -T | tail -n 20
[Mon Jan 21 03:14:02 2026] Lockdown: modprobe: Loading of unsigned module is restricted; see man kernel_lockdown.7
[Mon Jan 21 03:14:02 2026] lpfc: module verification failed: signature and/or required key missing - tainting kernel
[Mon Jan 21 03:14:02 2026] modprobe: ERROR: could not insert 'lpfc': Key was rejected by service

Значення: ви маєте чистий ланцюжок доказів: lockdown + помилка підпису + відхилення ключа.

Рішення: виправте підпис; якщо це шлях сховища на продакшен‑хості, плануйте контрольований break‑glass лише якщо немає альтернативного шляху.

Завдання 7 (Linux): перевірте, чи модуль підписано (modinfo)

cr0x@server:~$ modinfo lpfc | egrep -i 'signer|sig_key|sig_hashalgo|vermagic' || true
vermagic:       6.5.0-21-generic SMP preempt mod_unload

Значення: відсутність полів signer вказує, що модуль ймовірно не підписаний (або метадані відсутні).

Рішення: якщо Secure Boot увімкнено, несигновані модулі поза ядром неприйнятні. Використайте підписані пакети або підпишіть модуль самостійно з MOK.

Завдання 8 (Linux): підтвердьте версію ядра щодо збірки модуля

cr0x@server:~$ uname -r
6.5.0-21-generic

Значення: потрібен модуль, зібраний для цієї ABI ядра. Навіть підписаний модуль може не завантажитись при невідповідному vermagic.

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

Завдання 9 (Linux): перегляньте стан DKMS, щоб помітити непідписані перебудови

cr0x@server:~$ dkms status
zfs/2.2.2, 6.5.0-21-generic, x86_64: installed
nvidia/535.154.05, 6.5.0-21-generic, x86_64: installed

Значення: DKMS зібрав модулі для цього ядра. Це добре. Нічого не каже про підписування.

Рішення: підтвердіть підпис і реєстрацію MOK; «installed» не означає «завантажувано під Secure Boot».

Завдання 10 (Linux): перелічіть зареєстровані Machine Owner Keys (MOK)

cr0x@server:~$ sudo mokutil --list-enrolled | head -n 12
[key 1]
SHA1 Fingerprint: 9a:2b:1c:3d:4e:5f:60:71:82:93:a4:b5:c6:d7:e8:f9:0a:1b:2c:3d
Subject: CN=Ops Module Signing 2025
Issuer:  CN=Ops Module Signing 2025

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

Рішення: стандартизувати один організаційний ключ на середовище і забезпечити, щоб хук підписування DKMS його використовував послідовно.

Завдання 11 (Linux): підпишіть модуль (приклад) і підтвердьте

cr0x@server:~$ sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /root/MOK.priv /root/MOK.der /lib/modules/$(uname -r)/updates/dkms/zfs.ko

cr0x@server:~$ modinfo /lib/modules/$(uname -r)/updates/dkms/zfs.ko | egrep -i 'signer|sig_key|sig_hashalgo|vermagic'
vermagic:       6.5.0-21-generic SMP preempt mod_unload
sig_id:         PKCS#7
signer:         Ops Module Signing 2025
sig_key:        9A2B1C3D4E5F60718293A4B5C6D7E8F90A1B2C3D
sig_hashalgo:   sha256

Значення: модуль тепер несе дійсний підпис і ідентифікує підписувача.

Рішення: якщо підписувач відповідає зареєстрованому ключу, модуль має завантажитись під Secure Boot. Завантажуйте та перевіряйте функціональність пристрою.

Завдання 12 (Linux): перевірте відсутність блоків сховища після падіння драйвера

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT | head
NAME      SIZE TYPE MOUNTPOINT
sda       447G disk 
├─sda1      1G part /boot
└─sda2    446G part /

Значення: присутній лише диск для завантаження; SAN‑LUNи або NVMe‑пристрої відсутні — узгоджується з тим, що HBA/NVMe драйвер не завантажився.

Рішення: припиніть налагодження на рівні файлової системи. Спочатку виправте шлях завантаження драйвера, потім повторно проскануйте та підтвердіть multipath.

Завдання 13 (Linux): перевірте стан multipath (якщо застосовно)

cr0x@server:~$ sudo multipath -ll
mpatha (3600508b400105e210000900000490000) dm-2 IBM,2145
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 4:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 5:0:0:1 sdc 8:32 active ready running

Значення: є принаймні один активний шлях. Якщо цей вивід порожній або показує «failed faulty», шлях сховища/драйвер підірваний.

Рішення: якщо шляхи впали через падіння драйвера, не перезавантажуйте multipath без потреби; відновіть базовий HBA/NVMe драйвер спочатку.

Завдання 14 (Windows через PowerShell): знайдіть Code 52 і проблеми з підписом

cr0x@server:~$ pwsh -NoProfile -Command "Get-PnpDevice | Where-Object { $_.Status -ne 'OK' } | Select-Object -First 5 -Property Class,FriendlyName,Status,ProblemCode"
Class        FriendlyName                         Status   ProblemCode
-----        ------------                         ------   -----------
Net          Intel(R) Ethernet Controller X710     Error             52
SCSIAdapter  Vendor RAID Controller               Error             52

Значення: Windows ProblemCode 52 — класичне «Windows cannot verify the digital signature for the drivers required for this device.»

Рішення: не витрачайте час на перевстановлення тієї ж збірки. Отримайте коректно підписаний драйвер (WHQL/attestation), що відповідає збірці ОС і політиці безпеки.

Завдання 15 (Windows через PowerShell): перевірте, чи увімкнено test signing (його не має бути)

cr0x@server:~$ pwsh -NoProfile -Command "bcdedit /enum {current} | Select-String -Pattern 'testsigning|nointegritychecks|secureboot'"
testsigning              No
nointegritychecks        No

Значення: система не в режимі «хай завантажиться все підряд».

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

Завдання 16 (Linux): підтвердіть, що модуль дійсно завантажився після підписування

cr0x@server:~$ sudo modprobe zfs

cr0x@server:~$ lsmod | grep -E '^zfs\b'
zfs                  6356992  0

Значення: модуль завантажився. Тепер можна перевіряти, чи імпортуються пули, чи з’явилися NIC, чи перерахувались FC‑пристрої.

Рішення: підтвердіть end‑to‑end функціональність (пристрої присутні, файлові системи змонтовані, сервіси здорові) перед тим, як оголосити перемогу.

Жарт #2 (короткий, по суті): Політики безпеки як ремені безпеки: ви їх тільки докоряєте, доки не настане момент, коли вони врятують вас.

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

Міні-історія 1: аварія через неправильне припущення

Середня компанія експлуатувала флот хостів віртуалізації з двома Fibre Channel HBA. Інсталятор вендора використовували роками:
завантажити пакет, запустити інсталятор, перезавантажитись під час вікна обслуговування, і далі. Припущення було простим і неправильним: «якщо драйвер встановився, він завантажиться».

Потім змінився базовий стандарт безпеки. Нові хости постачалися з увімкненим Secure Boot за замовчуванням — тихо, бо саме так тепер прошивка відвантажується, і команда збірки пишалася «зміцненням». Ніхто не оновив рукопис, бо нічого не ламалось ще.
Це був ідеальний набір для ідеальної відмови: один кластер розширився «більш безпечними» вузлами, і вони виглядали здоровими до першого перезавантаження.

Прийшла ніч патчів. Половина кластера перезавантажилась і повернулась без усіх SAN‑LUNів. Сховища «зникли», VM відмовлялися стартувати,
а канал інцидентів заповнився теоріями про zoning комутаторів і помилки масивів. Масив був у порядку. FC‑комутатори були в порядку.
HBA були в порядку. FC‑драйвер не був довіреним.

Вбивчою деталлю був рядок у dmesg: “Key was rejected by service.” Secure Boot змінив правила, і модуль вендора поза ядром ніколи не був підписаний так, щоб ядро його прийняло.
Припущення «установлено = працює в runtime» коштувало їм годин.

Виправлення не було героїчним. Вони стандартизували налаштування прошивки, задокументували стан Secure Boot як поле інвентаризації, і перейшли
на шлях пакетів драйверів, що підтримував підпис модулів. Найціннішою зміною стала культура: відповідність драйверів стала частиною управління життєвим циклом, а не одноразовим кроком встановлення.

Міні-історія 2: оптимізація, яка повернулась бумерангом

Інженерна команда хотіла прискорити патчинг. Вони зібрали кастомне ядро з вузьким набором модулів і використовували DKMS для компіляції кількох вендорних
драйверів і модулів продуктивності під час складання образу. Було акуратно: менше пакетів, швидше завантаження, передбачувані версії ядра.

Вони також увімкнули Secure Boot як частину ініціативи сумісності. Але процес підписування не потрапив у pipeline образу.
У dev люди вимикали Secure Boot «тільки на час». У prod Secure Boot залишився ввімкненим. Ви вже розумієте подальший розвиток подій.

Бумеранг повернувся під час рутинного підвищення ядра. DKMS автоматично перебудував модулі при перезавантаженні. Модулі були правильними для
нового ядра, але несигнованими. Хости піднялись без мережевих інтерфейсів, що керуються цими DKMS‑модулями. Деякі вузли випали з кластера.
Інші завантажувалися, але мали знижену пропускну здатність і стрибки затримок, бо bonding переключився на повільніший інтерфейс.

Постмортем був неприємним, бо оптимізація здавалася розумною: компілювати під час складання образу, зменшити залежності, автоматизувати перебудови.
Бракувало одного: довіри. Кожна автоматична перебудова має автоматично підписуватись, а ключ підпису має реєструватись і управлятись як будь‑яка інша продакшен‑секретна інформація (ротація та контроль доступу).

Вони виправили це, зробивши підписування частиною pipeline, а не ручним кроком, і додали перевірку перед перезавантаженням: якщо хост завантажиться в ядро без підписаних потрібних модулів, оновлення блокується.
Це врятувало наступні вікна патчів від перетворення на несподівані аудити драйверів.

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

Інша організація експлуатувала сервери з інтенсивним використанням сховища на Linux з NVMe і кількома вендорними модулями. Вони не були
гламурні, але дисципліновані. Кожен хост мав записаний профіль «boot policy»: стан Secure Boot, SHA‑відбитки зареєстрованих MOK, і список
потрібних модулів, які мають завантажитись, щоб вузол вважався здоровим.

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

Одного дня вендор випустив оновлений бандл драйверів. Хтось спробував його швидко проштовхнути, бо «він покращує продуктивність». Preflight
перевірки показали, що підписувач модуля не відповідає зареєстрованому MOK ключу організації, і модуль не завантажиться під Secure Boot.
Розгортання зупинилося автоматично.

У них був час зв’язатися з вендором, отримати коректно підписаний пакет і протестувати його в середовищі з Secure Boot. Продакшен не побачив
відмови. Ніхто не піднявся в 3 ранку. Така практика була нудною, але саме це ви хочете від життєвого циклу драйверів.

Їхній секрет не був у якомусь дивовижному інструменті. Це було ставлення: «чи завантажиться під політикою» — як критерій релізу, а не як післяперезавантажувальний сюрприз.

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

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

1) LUN‑и сховища зникли після перезавантаження → HBA драйвер заблокований Secure Boot → встановити підписаний модуль або зареєструвати ключ підпису

Симптом: lsblk показує лише диск для завантаження; multipath порожній; FC‑пристрій присутній у lspci, але без драйвера в роботі.
Корінна причина: модуль відхилено: “Key was rejected by service” / “required key missing”.
Виправлення: використовувати пакет вендора, що підтримує Secure Boot, або підписати модуль зареєстрованим MOK; перевірити поля signer у modinfo.

2) NIC зник або перейменувався → модуль NIC поза ядром не завантажився → підтвердити модуль + підпис і перебудувати/підписати DKMS

Симптом: bonding не працює; ip link не показує очікуваний інтерфейс; маршрутизація зламана.
Корінна причина: після оновлення ядра DKMS перебудував модуль, але не підписав його; Secure Boot блокує.
Виправлення: забезпечити хуки підписування DKMS; зберігати MOK‑ключі консистентними; додати preflight‑перевірки перед перезавантаженням.

3) Windows Device Manager показує Code 52 → драйвер неправильно підписаний для політики → замінити на WHQL/attestation‑підписану версію

Симптом: пристрій показує «Windows cannot verify the digital signature…» і відмовляється запускатися.
Корінна причина: невірна гілка драйвера (test‑signed або вендор‑signed без прийнятного ланцюга), або ланцюжок підпису відкликано/заблоковано.
Виправлення: встановити коректний підписаний пакет; уникайте відключення примусової перевірки підписів; підтверджуйте через PnP статус і журнали подій.

4) «Працює до перезавантаження» → модуль завантажився один раз, потім політика змінилась або ядро змінилося → розглядайте перезавантаження як перевірку

Симптом: проблем немає під час роботи; після технічного перезавантаження пристрій зникає.
Корінна причина: застосування політики перевіряється під час завантаження/завантаження модуля; існуючі сесії маскують майбутні помилки при старті.
Виправлення: тестуйте перезавантаження в staging з ідентичною прошивкою/політикою; заплануйте періодичні контрольовані перезавантаження, щоб вивести приховані проблеми на поверхню.

5) Випадкова підмножина хостів відмовляє → дрейф політик по флоту → інвентаризуйте стан Secure Boot і зареєстровані ключі

Симптом: той самий драйвер працює на деяких хостах, на інших — ні.
Корінна причина: неконсистентні налаштування BIOS Secure Boot, різні версії db/dbx відклику, різна реєстрація MOK або змішані налаштування режиму lockdown.
Виправлення: базувати налаштування прошивки; зберігати стан політики хостів у CMDB/інвентарі; застосовувати під час провізування хостів.

6) «Ми вимкнули Secure Boot, щоб виправити» → короткострокове відновлення, довготривала крихкість → використовуйте break‑glass з rollback і подальшими діями

Симптом: сервіс негайно відновлено відключенням контролю, але тепер середовище «спеціальне».
Корінна причина: аварійне рішення стало постійним, бо корінна проблема (процес підписування) ніколи не реалізована.
Виправлення: якщо потрібно відключити контроль, задайте часові обмеження, документуйте це і створіть завдання на повторне увімкнення з підписаними модулями, протестованими заздалегідь.

Контрольні списки / покроковий план

Checklist A: перед оновленням ядра (Linux)

Зафіксуйте стан політики: Secure Boot увімкнено/вимкнено, режим lockdown, зареєстровані MOK‑відбитки.
Перелікуйте потрібні модулі: сховище (HBA/NVMe), мережа, GPU, файлові системи (наприклад, ZFS), надбудови віртуалізації.
Перевірте наявність модуля для нового ядра: переконайтесь, що файл модуля існує під /lib/modules/NEWKERNEL/.
Перевірте підписи: modinfo має показувати поля signer; підписувач має відповідати зареєстрованому ключу.
Заплануйте перевірку перезавантаження: перезавантажте канарку з увімкненим Secure Boot; перевірте перерахування пристроїв і здоров’я сервісів.
Майте шлях відкоту: збережіть попереднє ядро; переконайтесь, що завантажувач може обрати його віддалено.

Checklist B: коли драйвер блокується в продакшені

Припиніть здогадки: зберіть dmesg / journal докази про помилку підпису або відхилення ключа.
Підтвердіть наявність апаратури: lspci та прив’язка драйвера lspci -k.
Підтвердіть політику: mokutil --sb-state, режим lockdown.
Підтвердіть підпис модуля: поля signer у modinfo.
Оберіть один шлях відновлення:
- Встановити коректно підписаний пакет драйвера.
- Зареєструвати MOK і підписати модулі.
- Break‑glass: тимчасово послабити enforcement (задокументувати, обмежити за часом, повернути назад).
Підтвердіть end‑to‑end: пристрої присутні, multipath здоровий, сервіси працюють, продуктивність в нормі.
Запобігайте повторенню: додайте preflight‑перевірки в pipeline патчування; інвентаризуйте стан політики прошивки.

Checklist C: побудуйте стійкий процес підписування (Linux DKMS‑орієнтовані середовища)

Створіть виділений ключ підпису модулів для середовища (prod vs non‑prod розділення має значення).
Зберігайте приватні ключі безпечно (обмежений доступ, аудит використання, план ротації).
Реєструйте публічний ключ через MOK на кожному Secure Boot‑хості під час провізування.
Автоматизуйте підписування після збірки DKMS (post‑install хуки) і перевіряйте підписи в CI.
Блокуйте перезавантаження без preflight‑перевірок, щоб хости не могли перезавантажитися в стан, де потрібні модулі не завантажаться.
Документуйте break‑glass з явно призначеним власником і терміном повторного ввімкнення.

FAQ

1) Що фактично означає «несигнований драйвер»?

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

2) Чому це проявляється лише після перезавантаження?

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

3) Чи прийнятно вимкнути Secure Boot як рішення?

Як тимчасовий break‑glass для відновлення сервісу інколи — так, якщо ви розумієте ризик і можете швидко повернути назад. Як постійне рішення — ні.
Ви накопичите винятки, втратите аудит і рано чи пізно провалите перевірку на відповідність або аудит безпеки з аргументом, який важко відстоювати.

4) Чому Linux показує «tainting kernel»?

«Taint» — це позначка ядра, що воно запускає код, який не відповідає звичайним очікуванням підтримки або політиці (часто пропрієтарний або несигнований).
Це сигнал для налагодження/підтримки. У середовищах із Secure Boot + lockdown часто модуль взагалі не пройде і «taint» може не з’явитись — модуль буде заблокований.

5) У чому різниця між підписом модуля і реєстрацією ключа?

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

6) Чому DKMS‑драйвери спричиняють стільки інцидентів?

DKMS автоматично перебудовує модулі при зміні ядра. Це зручно, але вводить новий крок: кожен перебудований модуль треба підписати. Без автоматизації
перше перезавантаження після оновлення ядра стає тестом вашої дисципліни підписування у продакшені.

7) Як відкликання сертифікатів ламають драйвери, що «підписані»?

Довіра — це не лише наявність підпису; це питання прийнятності підписувача сьогодні. Якщо сертифікат підпису відкликано або корінь визнано недовіреним,
ОС може відхилити бінарники, підписані ним. Оновлення прошивки з відкликом (dbx) також можуть анулювати раніше прийняті компоненти.

8) Чому Windows показує Code 52, а Linux — “Required key not available”?

Різні платформи, одна тема: код ядра у режимі драйвера має валідуватися проти довіреного ланцюга. Windows відображає це через PnP коди проблем і журнали подій;
Linux — через dmesg/journal і помилки завантаження модулів.

9) Як запобігти дрейфу «працює на деяких хостах»?

Ставте стан завантаження як конфігурацію, а не як особливість: стандартизуйте налаштування прошивки, зберігайте стан Secure Boot, централізовано керуйте зареєстрованими ключами
і забезпечуйте однакові пакети драйверів та процес підписування для всіх хостів. Флот зі змішаними політиками — інкубатор відмов.

10) Якщо підписи не гарантують якості, навіщо вони взагалі потрібні?

Тому що підписи встановлюють керовану межу довіри і підзвітність. Вони не допускають випадковий код у режимі ядра, зменшують поверхню атаки і змушують мати процес.
Сам процес — ось що важливо.

Висновок: кроки, що запобігають наступному «таємничому апаратному» збою

Помилки через несигновані драйвери — найганебніший тип операційних інцидентів: апарат у порядку, вікно змін тане, і виправлення виглядає як суперечка з швейцаром щодо дрес‑коду, про який ви не знали.
Ліки — не героїчні дії. Це управління.

Зробіть наступне, у цьому порядку:

Інвентаризуйте стан політик по флоту: Secure Boot, lockdown, зареєстровані ключі.
Визначте «обов’язкові» драйвери для сховища, мережі, GPU і файлових систем; зафіксуйте їх явно.
Додайте preflight‑перевірки до процесу патчування: перевірка наявності модулів, відповідність vermagic, підписувач — зареєстрований ключ.
Автоматизуйте підписування для DKMS і будь‑яких модулів поза ядром; ставте ключі підпису в категорію продакшен‑секретів.
Тестуйте перезавантаження у середовищі, що відповідає продакшен‑політиці, а не в поблажливій лабораторії.
Документуйте break‑glass і задавайте часові межі. Якщо вимкнули enforcement, заплануйте роботу з повторного ввімкнення до того, як це стане «наш спосіб роботи».

Безпека не зламала ваш апарат. Ваш життєвий цикл драйверів — зламав. Виправте життєвий цикл, і апарат знову стане нудним — саме цього заслуговує продакшен.