Помилки Secure Boot після інсталяції: виправлення невідповідності ключа та режиму

Ментальна модель: режими, ключі та що насправді дає збій

Secure Boot — це не «перемикач». Це система довірчого ланцюжка, яку реалізує UEFI-прошивка. Прошивка вирішує, чи дозволено виконання наступного файлу. Цим «наступним виконуваним» зазвичай є shim (у багатьох дистрибутивах Linux), який потім перевіряє GRUB, а GRUB — ядро (іноді й модулі ядра).

Користувацький режим проти режиму налаштування: два стани, що мають значення

UEFI Secure Boot має два релевантні робочі стани:

• Режим налаштування (Setup Mode): платформний ключ (PK) не встановлений. Прошивка фактично «не належить» нікому. Ви можете додавати ключі без авторизації, тому що немає PK, який би захищав власність. Це стан, у який часто потрапляють при «очищенні ключів Secure Boot».
• Користувацький режим (User Mode): PK встановлений. Бази ключів захищені, і оновлення ключів потребують авторизації. Це нормальний очікуваний стан системи, яка застосовує Secure Boot.

Багато «помилок Secure Boot після інсталяції» трапляються тому, що машина в режимі Setup (або має порожні db/dbx), тоді як ОС очікує присутності ланцюга третіх сторін Microsoft або ваших кастомних ключів. Навпаки також буває: прошивка в User Mode з ключами вендора, а ви встановили ядро чи завантажувач, які не підписані довіреним ключем.

Бази ключів: PK, KEK, db, dbx, і чому dbx — це «вісник»

• PK (Platform Key): встановлює власність платформи. Якщо PK відсутній — ви в режимі Setup.
• KEK (Key Exchange Key): дозволяє оновлювати дозволені/заборонені списки.
• db: дозволені підписи/хеші. Якщо підпис вашого завантажувача ланцюжиться до сертифіката в db — він може виконуватися.
• dbx: заборонені підписи/хеші (список відкликання). Якщо dbx каже «ні», то ні — навіть якщо db дозволяє.

Дистрибутиви, які підтримують Secure Boot, зазвичай постачають підписаний shim. Цей shim підписано ключем, що ланцюжиться до Microsoft третьої сторони UEFI CA, який багато вендорів додають у db за замовчуванням. Далі shim використовує власний вбудований сертифікат і/або список MOK для валідації GRUB і ядрa.

Отже, що таке «невідповідність ключ/режим» на практиці?

Невідповідність виникає, коли одна сторона припускає корінь довіри, який не відповідає дійсності:

• Прошивка застосовує Secure Boot у User Mode, але встановлений завантажувач/ядро не підписані довіреним ланцюжком.
• Прошивка в Setup Mode (PK очищено), але ОС очікує ключі вендора/Microsoft, тож підписи не проходять як очікувалося (або взагалі нічого не контролюється, але встановлений ланцюжок все одно розраховує на певне середовище).
• У вас є кастомні ключі, але ви забули їх зареєструвати (або зареєстрували в MOK, а потрібно було в db; або навпаки).
• dbx оновлено і тепер блокує старий shim/grub (помилки, пов’язані з SBAT, часто тут).

Цитата, яку варто пам’ятати, коли дуже хочеться «просто вимкнути це»: (парафраз) «Сподівання — не стратегія.» — Джин Кренц. Secure Boot не ідеальний, але вимикати його через незручності — це те саме, що знімати ремінь безпеки, бо він м’яко мнеться.

Жарт #1: Secure Boot — як охоронець у нічному клубі з блокнотом. Якщо вашого імені немає в списку, вам не світить — навіть якщо ви «знаєте власника».

Цікавинки та історичний контекст (бо без історії тут ніяк)

1. UEFI Secure Boot увійшов у маси разом із апаратами епохи Windows 8. Його не винайшли, щоб дошкульно ставитися до Linux; відповідь була націлена на bootkit’и та стійке шкідливе ПЗ нижче рівня ОС.
2. Третя сторона UEFI CA від Microsoft стала де-факто «містком» для Linux. Багато вендорів включають її в db, що дозволяє дистрибутивам завантажувати Microsoft-підписаний shim без вимоги, щоб кожен користувач керував своїми ключами.
3. Shim існує тому, що виробники прошивки не хотіли включати ключі кожного дистрибутива. Один підписаний shim плюс дистрибутивне керування довірою масштабовано; захаращення db сертифікатами всіх — ні.
4. Оновлення dbx фактично є глобальними «відкликаннями». Коли виявляють вразливість у широко вживаному компоненті завантаження, dbx може його блокувати на системах — корисно, але суворо.
5. SBAT запровадили, щоб зробити відкликання більш детальним. Замість відкликання цілого сертифіката (з побічними наслідками), метадані SBAT можуть блокувати конкретні вразливі збірки.
6. «Очищення ключів Secure Boot» — не те саме, що «вимкнення Secure Boot». Очищення ключів часто переводить у режим Setup і може створити ще дивнішу поведінку, ніж просто відключення примусового контролю.
7. MOK (Machine Owner Key) — механізм на рівні shim, не на рівні прошивки. MOK зручний для підписування ядер/модулів, але він не заповнює автоматично firmware db.
8. Деякі вендори постачають систему з увімкненим Secure Boot, але дозволяють сторонні ключі; деякі — ні. Одна перемикач у BIOS «Allow Microsoft 3rd party UEFI CA» вирішує, чи завантажаться поширені Linux shim’и.
9. Підпис модулів ядра суміжний, але не тотожний. Ви можете успішно завантажитися, але драйвери можуть не завантажитися, бо примусове підписування модулів — окрема річ від валідації UEFI Secure Boot.

Швидка діагностика (перевірте в цьому порядку)

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

1) Перевірте режим прошивки та стан Secure Boot

• Система завантажена в режимі UEFI (а не legacy/CSM)?
• Secure Boot увімкнено та активне?
• Прошивка в режимі Setup (PK відсутній) чи в User Mode?

2) Визначте компонент, що дає збій

• Повідомлення від прошивки перед запуском shim (“Security violation”, “Invalid signature”)?
• Shim запускається, але відхиляє GRUB/ядро (“Verification failed: (15)”, “SBAT policy violation”)?
• Система завантажується, але потім відхиляє драйвери (NVIDIA, ZFS, Wi‑Fi)? Це вже сфера підписування модулів.

3) Підтвердіть, які ключі реально внесені

• Вміст firmware db/dbx (принаймні наявність/цілісність).
• Зміст списку MOK, якщо використовується shim/MOK.
• Чи увімкнено «Microsoft 3rd party UEFI CA» у прошивці.

4) Визначте вашу модель довіри

• Корпоративна інфраструктура: зазвичай зберігають ключі вендора + Microsoft, використовують штатний shim дистрибутива, застосовують MOK для власних ядер/модулів.
• Повний контроль: використовують кастомні ключі (власний PK/KEK/db), підписують усе, що завантажується. Більше роботи, більше впевненості.
• Тестовий бокс: якщо машина не підключена до нічого чутливого, тимчасове відключення Secure Boot прийнятне, але задокументуйте це і не прикидайтеся, що «все безпечно».

Підписи помилок: що насправді означає повідомлення

Прошивка: «Security violation» / «Invalid signature» до появи меню завантажувача

Прошивка відхилила EFI-бінарник. Типові причини:

• Завантажувач не підписано ключем, що є в db.
• Хеш/підпис завантажувача в dbx (відкликаний).
• Ви встановили GRUB напряму (без підпису) замість шляху через shim, або перезаписали підписаний бінарник.
• Прошивка налаштована забороняти сторонні CA.

Shim: «Verification failed: (15)» після вибору запису

Shim запустився, отже прошивка прийняла shim. Тепер shim відхиляє GRUB або ядро, бо не може підтвердити наступний етап за вбудованим сертифікатом або MOK.

SBAT policy violation

Це часто логіка відкликання, яка виконує своє завдання. Ваш збірник shim/grub досить старий (або маркований як вразливий), і поточний dbx/SBAT політика блокує його. Виправлення зазвичай — завантажити новіший shim/grub, а не боротися зі списком відкликання.

Система завантажується, але драйвери не працюють: «Required key not available»

Ядро застосовує примусове підписування модулів (часто через увімкнений Secure Boot і режим lockdown). Ваш сторонній модуль (NVIDIA, DKMS, ZFS, VirtualBox) не підписано ключем, якому ядро довіряє. Це не проблема firmware db; це питання ключів у keyring ядра / MOK.

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

Це перевірки, які я виконую на реальних системах. Кожне завдання містить: команду, що означає її вивід, і яке рішення з цього випливає. Команди припускають Linux; якщо не можете завантажитися нормально, використовуйте live USB у режимі UEFI і chroot там, де вказано.

Завдання 1: Підтвердити, що система завантажена в режимі UEFI

cr0x@server:~$ test -d /sys/firmware/efi && echo "UEFI boot" || echo "Legacy boot"
UEFI boot

Значення: Якщо отримуєте “Legacy boot”, стан Secure Boot не має значення, бо ви не в UEFI.

Рішення: Якщо legacy — спочатку виправте режим завантаження у прошивці (вимкніть CSM/Legacy). Не чіпайте ключі.

Завдання 2: Перевірити, чи увімкнено Secure Boot (огляд з ОС)

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

Значення: «enabled» означає, що ядро вважає Secure Boot активним. «disabled» може означати, що воно вимкнено у прошивці або ви завантажили шлях, що його обходить.

Рішення: Якщо disabled, але очікували enabled — перевірте налаштування прошивки або режим legacy.

Завдання 3: Перевірити, чи прошивка в режимі Setup (PK відсутній)

cr0x@server:~$ mokutil --pk
PK is not enrolled

Значення: Відсутність PK зазвичай означає режим Setup.

Рішення: Якщо PK не внесено і ви хочете застосовувати примус, потрібно відновити/внести ключі (заводські або кастомні PK/KEK/db).

Завдання 4: Перевірити наявність Microsoft та ключів вендора (швидка перевірка)

cr0x@server:~$ sudo efi-readvar -v db | head
Variable db, length 2346
PKCS7 signature:
Signer: Microsoft Corporation UEFI CA 2011

Значення: Наявність підписувача Microsoft UEFI CA вказує, що спільний корінь довіри присутній у db.

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

Завдання 5: Інспектувати dbx на предмет очевидних відкликань

cr0x@server:~$ sudo efi-readvar -v dbx | head
Variable dbx, length 17892
Signature list 1
Signature type: X509

Значення: dbx заповнений. Це нормально. Комбінація «занадто новий dbx + застарілий shim» може порушити завантаження після оновлень.

Рішення: Якщо помилка пов’язана з SBAT, у пріоритеті оновити shim/grub, а не відкатувати dbx.

Завдання 6: Перевірити, які EFI-бінарники існують і який файл ви завантажуєте

cr0x@server:~$ sudo ls -R /boot/efi/EFI | sed -n '1,80p'
/boot/efi/EFI:
Boot  ubuntu

/boot/efi/EFI/Boot:
BOOTX64.EFI

/boot/efi/EFI/ubuntu:
grubx64.efi  mmx64.efi  shimx64.efi

Значення: Наявність shimx64.efi вказує на шлях, дружній до Secure Boot. Якщо є лише grubx64.efi і він непідписаний, прошивка може відхилити його.

Рішення: Якщо shim відсутній — перевстановіть пакет shim-signed дистрибутива і повторно зареєструйте запис завантаження.

Завдання 7: Перевірити UEFI-записи та на який файл вони вказують

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0003* ubuntu	HD(1,GPT,4d7b...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* UEFI OS	HD(1,GPT,4d7b...,0x800,0x100000)/File(\EFI\Boot\BOOTX64.EFI)

Значення: Якщо запис вказує прямо на grubx64.efi, а Secure Boot увімкнено, ви ризикуєте, що файл буде відхилений.

Рішення: Вкажіть запис на shim там, де потрібно, або виправте підпис/ланцюжок довіри для GRUB.

Завдання 8: Підтвердити, що shim/grub насправді підписані (перевірка файлу)

cr0x@server:~$ sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi
signature 1
image signature issuers:
 - /CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - /CN=Canonical Ltd. Secure Boot Signing

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

Рішення: Якщо він непідписаний — перевстановіть зі схвалених пакетів. Не копіюйте EFI-бінарники звідки попало.

Завдання 9: Перевірити стан реєстрації MOK (поширено після встановлення DKMS-модулів)

cr0x@server:~$ mokutil --list-enrolled | head
[key 1]
SHA1 Fingerprint: 9a:7c:...
Subject: CN=Local DKMS Signing

Значення: Локально зареєстрований ключ існує. Це добре, якщо вам потрібно завантажувати підписані DKMS-модулі.

Рішення: Якщо модулі ядра відмовляють із «Required key not available», ймовірно потрібно зареєструвати ключ або підписати модулі наявним ключем.

Завдання 10: Подивитися блокування ядра та ефекти Secure Boot

cr0x@server:~$ dmesg | grep -i -E 'secureboot|lockdown' | head -n 20
[    0.000000] Secure boot enabled
[    0.532101] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7

Значення: Активний режим lockdown ядра; певні операції (наприклад доступ до сирих MSR, kexec у деяких режимах) можуть бути обмежені.

Рішення: Якщо якийсь інструмент перестав працювати після увімкнення Secure Boot, підтвердіть, що це наслідок lockdown, а не «випадкова регресія».

Завдання 11: Діагностика збоїв підписів модулів (симптоми NVIDIA/DKMS)

cr0x@server:~$ sudo journalctl -k -b | grep -i -E 'module verification|Required key not available' | head
kernel: Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
kernel: nvidia: module verification failed: signature and/or required key missing

Значення: Система завантажилася нормально; тепер ядро відмовляє модулю.

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

Завдання 12: Перевірити версії встановлених пакетів shim/grub (чи не застарілі компоненти?)

cr0x@server:~$ dpkg -l | egrep 'shim-signed|grub-efi-amd64-signed' || true
ii  grub-efi-amd64-signed  1.187.3+2.12-1ubuntu7  amd64  GRUB EFI signed kernel loader
ii  shim-signed            1.58+15.7-0ubuntu1     amd64  Secure Boot chain-loading bootloader (Microsoft-signed)

Значення: Ви можете зіставити ці версії з тим, наскільки система сумісна із SBAT і виправленнями.

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

Завдання 13: Перевірити підпис образу ядра (якщо ваш дистрибутив підписує ядра)

cr0x@server:~$ sbverify --list /boot/vmlinuz-$(uname -r) | head
signature 1
image signature issuers:
 - /CN=Canonical Ltd. Secure Boot Signing

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

Рішення: Якщо невідписане, ви, ймовірно, використовуєте кастомне ядро, яке треба підписати і зареєструвати в MOK, або встановили ядро поза набором підписаних пакетів дистрибутива.

Завдання 14: Відновити EFI-запис, щоб вказувати на shim (часте просте виправлення)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "ubuntu-shim" -l '\EFI\ubuntu\shimx64.efi'
BootCurrent: 0003
BootOrder: 0007,0003,0001,0002
Boot0007* ubuntu-shim	HD(1,GPT,4d7b...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Значення: Ви створили новий запис, що завантажує shim безпосередньо.

Рішення: Якщо після цього Secure Boot працює — попередній запис вказував на невірний бінарник.

Завдання 15: Визначити, чи знаходитеся у конфігурації «прошивка не дозволяє сторонні»

cr0x@server:~$ sudo efi-readvar -v db | grep -i -E 'Microsoft Corporation UEFI CA 2011|Windows UEFI' | head
Signer: Microsoft Windows UEFI Driver Publisher
Signer: Microsoft Corporation UEFI CA 2011

Значення: Наявність підписувачів вказує, що firmware db містить ключі Microsoft. Проте деякі прошивки мають окремий перемикач, що вимикає використання сторонніх CA.

Рішення: Якщо db містить CA, але shim все одно не завантажується, перегляньте налаштування прошивки щодо «third-party» або режим «Standard/Custom» ключів вендора.

Завдання 16 (live USB + chroot): Чисто перевстановити підписані компоненти завантаження

cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt$i; done
cr0x@server:~$ sudo chroot /mnt bash -lc 'apt-get update && apt-get install --reinstall shim-signed grub-efi-amd64-signed && update-grub'
Reading package lists... Done
Setting up shim-signed ...
Setting up grub-efi-amd64-signed ...
Generating grub configuration file ...

Значення: Ви примусово чисто розгортаєте підписані EFI-бінарники і перебудовуєте конфігурацію GRUB.

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

Виправлення невідповідності ключ/режим: практичні шляхи

Є три розумні стратегії. Оберіть одну. Їхнє змішування — шлях у пекло «працює до наступного оновлення».

Шлях A: Заводські налаштування вендора + штатний shim дистрибутива (рекомендовано для більшості)

Коли обирати: ноутбуки, сервери зі стандартними дистрибутивами, корпоративні кінцеві точки, все, де потрібна стандартна підтримувана позиція.

Ціль: Прошивка в User Mode із ключами вендора/Microsoft. Ви завантажуєтесь через підписаний штатний shim і підписаний GRUB/ядро. Якщо потрібні DKMS-модулі — підписуйте їх і реєструйте через MOK.

Що робити:

• У прошивці: завантажити ключі за замовчуванням (зазвичай «Install factory default keys» або «Restore factory keys»).
• Переконатися, що «Microsoft 3rd party UEFI CA» увімкнено, якщо ваш дистрибутив його використовує.
• В ОС: перевстановити shim-signed і grub-efi-*-signed, переконатися, що запис завантаження вказує на shim.
• Якщо у вас є непідписані модулі: згенерувати локальний ключ підпису, зареєструвати його через MOK manager, підписати модулі.

Шлях B: Повні кастомні ключі (PK/KEK/db) для середовищ із високим контролем

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

Ціль: Ви контролюєте PK/KEK/db. Ви підписуєте shim/grub/ядро самі (або використовуєте shim, підписаний вашими ключами і вносите їх). Ви підтримуєте власну логіку відкликання.

Жорстка правда: це операційна робота. Ротація ключів, процедури відновлення, особливості UI прошивки і уникнення «запалення» системи — тепер ваші проблеми. Якщо не готові до цього — обирайте Шлях A.

Шлях C: Вимкнути Secure Boot (лише якщо ви серйозно)

Коли обирати: короткострокова аварійна відновлення сервісу, лабораторні машини або як свідоме політичне рішення з компенсуючими заходами.

Ціль: Надійно завантажитися зараз, а потім повернутися і реалізувати A або B правильно.

Жарт #2: Вимкнення Secure Boot, щоб виправити Secure Boot — як вирішити проблему сигналізації, витягнувши батарейку. Шум припиняється; вогонь нічого не хвилює.

Поширені ситуації «невідповідності режимів» і чисті виправлення

Ситуація: PK очищено (Setup Mode), Secure Boot «увімкнено», і нічого не завантажується стабільно

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

Виправлення: відновіть заводські ключі (Шлях A) або внесіть кастомні PK/KEK/db (Шлях B). Не залишайте систему напіввласною.

Ситуація: Прошивка не дозволяє сторонні CA

Чому так: деякі системи мають налаштування, що довіряє лише ключам Windows у виробничому профілі. Ваш Linux shim залежить від Microsoft third-party UEFI CA.

Виправлення: увімкніть сторонні CA у прошивці, або внесіть сертифікат shim дистрибутива в db (рідше і складніше), або переходьте на повні кастомні ключі.

Ситуація: Ви встановили кастомне ядро або самобудований GRUB

Чому так: ви замінили підписані компоненти на непідписані, і Secure Boot зробив свою роботу.

Виправлення: підпишіть бінарники і внесіть довіру належним чином. Або поверніться до пакетів, підписаних дистрибутивом.

Ситуація: SBAT policy violation після оновлень

Чому так: dbx/SBAT відкликав старі вразливі збірки shim/grub. Тепер ваші встановлені EFI-бінарники заблоковано.

Виправлення: оновіть shim/grub до невідкликаної версії з rescue-середовища, потім завантажуйтеся нормально. Уникайте відкату dbx, якщо ви не готові прийняти відомий ризик.

Три корпоративні історії з життя «в мене на ноуті працювало»

Інцидент №1: відмова через неправильні припущення

Компанія розгортала новий образ Linux для робочих станцій розробників. Команда образів протестувала його на трьох моделях ноутбуків і визнала все в порядку. У понеділок черга у службу підтримки перетворилася на DDoS — з доказами. Полфлоту почали завантажуватися в помилку прошивки про недійсні підписи.

Неправильне припущення було тонким: «Усі вендори постачають Microsoft third-party UEFI CA у db». Багато постачають. Деякі — ні. А деякі постачають, але ховають її за BIOS-перемикачем, що за замовчуванням вимкнений у певних регіонах або профілях безпеки.

Що зробило ситуацію гіршою: образ був збудований з очікуванням, що shim приймуть, але запис завантаження вказував прямо на grubx64.efi на підмножині машин через упаковочну особливість під час іміджування. На машинах з лояльним db все завантажувалося; на строгих — «мертві з народження».

Виправлення не було героїчним. Вони стандартизували налаштування прошивки через інструменти управління, явно увімкнули сторонні CA там, де дозволено, і оновили процес іміджування, щоб завжди реєструвати запис на shim. Справжнім успіхом став постмортем: додали перевірку preflight у стейджинг, яка валідує Secure Boot для кожного SKU обладнання, а не лише «те, що в лабораторії».

Інцидент №2: оптимізація, що зіграла злий жарт

Платформна команда хотіла швидшої ітерації ядра для сервісу з низькою затримкою. Хтось запропонував збирати кастомне ядро з невеликою кількістю патчів і розгортати його на флоті edge-серверів. Також хотіли зберегти Secure Boot увімкненим — правильна ідея.

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

Відновили роботу, завантажившись у попереднє підписане ядро через fallback-запис завантажувача — на машинах, де GRUB ще мав таку опцію. На машинах, де конфіг було «спрощено» до одного запису (щоб зекономити секунду завантаження), fallback відсутній. Ті вимагали ручного порятунку.

Урок: Secure Boot не ламає ваше розгортання. Ваше розгортання ламає ваше розгортання. Якщо ви поставляєте кастомні ядра, підписування не може бути післямірним. Це артефакт релізу.

Інцидент №3: нудна, але правильна практика, що врятувала день

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

У них була політика: щоразу після оновлення прошивки вони записували стан Secure Boot (увімкнено/вимкнено), стан реєстрації PK і поточні шляхи EFI-записів. Запис зберігали в тикеті зміни. Було нудно, рутинно, і ніхто за це не отримав підвищення.

Одного кварталу оновлення прошивки тихо скинуло налаштування ключів Secure Boot на двох вузлах. Вузли все ще завантажувалися, але пізніше модуль ядра для моніторингу HBA перестав завантажуватися з «Required key not available». Інженер на виклику не панікував. Він порівняв запис зміни, побачив, що MOK було стерто, повторно зареєстрував ключ під час вікна обслуговування і повторно підписав модулі. Немає втрати даних, немає тривалого простою, без драми.

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

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

1) «Verification failed: (15)» після інсталяції

• Симптом: shim запускається, але вибір запису Linux завершується помилкою.
• Причина: GRUB або ядро не підписані ключем, якому довіряє shim; MOK не внесено; або ви замінили підписаний GRUB на непідписаний.
• Виправлення: перевстановіть підписаний пакет grub; переконайтеся, що запис вказує на shim; внесіть MOK і підпишіть ядро, якщо ви використовуєте кастомні збірки.

2) Прошивка: «Invalid signature» перед появою будь-якого меню

• Симптом: негайне відхилення завантаження EFI-бінарника.
• Причина: firmware db не довіряє підписувачу бінарника, або сторонні CA вимкнено, або бінарник відкликано в dbx.
• Виправлення: відновіть заводські ключі і увімкніть сторонні CA; або внесіть свої ключі і підпишіть EFI-бінарник; або оновіть shim/grub, якщо вони відкликані.

3) SBAT policy violation після «звичайного» оновлення

• Симптом: система завантажувалася вчора; сьогодні shim відмовляє з повідомленням SBAT.
• Причина: ваш shim/grub старший за політику відкликання, яку тепер застосовує dbx/SBAT.
• Виправлення: завантажте rescue media, chroot, оновіть/повторно встановіть пакети shim/grub, перевірте, що запис вказує на оновлений shim.

4) Завантажується нормально, але NVIDIA/ZFS/VirtualBox падає: «Required key not available»

• Симптом: відсутній драйвер, збірка DKMS пройшла, але модуль не завантажується.
• Причина: модуль не підписано ключем, що є у довірених ключах ядра; MOK відсутній або стертий.
• Виправлення: внесіть MOK і підпишіть модулі; повторно ініціюйте підписування DKMS; перевірте mokutil --list-enrolled.

5) Хтось «очистив ключі» для усунення проблем, і тепер усе дивно

• Симптом: режим Setup, непослідовна поведінка між перезавантаженнями, перемикачі Secure Boot поводяться неочікувано.
• Причина: PK видалено; платформа не в стабільному стані User Mode.
• Виправлення: відновіть заводські ключі (Шлях A) або налаштуйте повну кастомну множину ключів (Шлях B). Перестаньте очищувати ключі як крок діагностики.

6) Dual-boot раптово зламався після перевстановлення Windows або Linux

• Симптом: одна ОС завантажується; інша відмовляє із помилками підписів або відсутніми записами.
• Причина: записи завантаження перезаписані; EFI-бінарники замінені; ключі вендора можуть не змінюватися, але шлях тепер вказує на непідписаний GRUB.
• Виправлення: відновіть записи за допомогою efibootmgr; перевстановіть shim/grub для Linux; підтвердьте, що кожна ОС вказує на свій підписаний завантажувач.

7) «SecureBoot disabled» в ОС, але прошивка каже увімкнено

• Симптом: розбіжність між UI прошивки і mokutil --sb-state.
• Причина: завантажилися в legacy режим, або через шлях, що не застосовує Secure Boot, або особливості реалізації прошивки.
• Виправлення: перевірте UEFI-завантаження через /sys/firmware/efi; перевірте записи завантаження; відключіть CSM.

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

Чекліст 1: Мінімальні перевірки перед тим, як чіпати налаштування прошивки

1. Підтвердіть UEFI-завантаження: test -d /sys/firmware/efi.
2. Перевірте стан Secure Boot у рантаймі: mokutil --sb-state.
3. Перевірте реєстрацію PK: mokutil --pk.
4. Огляньте записи завантаження: efibootmgr -v.
5. Перелічіть EFI-бінарники: ls -R /boot/efi/EFI.

Якщо не можете завантажитися: виконайте ці кроки з live USB, завантаженого в режимі UEFI, після монтування ESP.

Чекліст 2: Шлях ремонту для «неправильного запису завантаження» (швидке виправлення)

1. Примонтуйте ESP і переконайтеся, що shim існує: /boot/efi/EFI/<distro>/shimx64.efi.
2. Створіть новий UEFI-запис, що вказує на shim за допомогою efibootmgr -c ... -l '\EFI\...\shimx64.efi'.
3. Перемістіть його вгору в BootOrder (або задайте явно).
4. Перезавантажтеся і переконайтеся, що пройшли валідацію прошивки.

Чекліст 3: Шлях ремонту для «старий shim/grub відкликано» (SBAT/dbx невідповідність)

1. Завантажте актуальне rescue/live середовище в режимі UEFI.
2. Примонтуйте root FS і ESP; bind-mount /dev, /proc, /sys, /run.
3. Chroot і перевстановіть підписані пакети shim/grub.
4. Запустіть update-grub (або еквівалент дистрибутива).
5. Перевірте, що запис вказує на оновлений shim.

Чекліст 4: Шлях ремонту для «потрібне підписування модулів» (завантажується, але драйвери падають)

1. Підтвердіть збої модулів у логах: journalctl -k -b.
2. Перевірте список MOK: mokutil --list-enrolled.
3. Якщо підходящого ключа немає: створіть його (через інструменти дистрибутива), зареєструйте, перезавантажтеся через MOK manager.
4. Підпишіть модулі (або перебудуйте DKMS, щоб воно підписувало автоматично).
5. Підтвердіть завантаження модуля: modprobe <module> і перевірте логи.

Чекліст 5: Політика безпечного розгортання для флоту (що стандартизувати)

1. Документуйте, чи ви покладаєтеся на Microsoft third-party UEFI CA або на кастомні ключі.
2. Стандартизujte налаштування прошивки (Secure Boot увімкнено, сторонні CA дозволені якщо потрібно, CSM вимкнено).
3. Фіксуйте або стаджуйте оновлення shim/grub; не дозволяйте застарілим EFI-бінарникам лишатися.
4. Майте робочий процес порятунку, що може оновити shim/grub з офлайн-носія.
5. Відстежуйте процедури реєстрації MOK для систем з DKMS.

Питання й відповіді

1) Чому Secure Boot впав одразу після інсталяції? Я нічого не міняв.

Бо інсталятор мог щось змінив. Він міг створити запис завантаження, що вказує на невірний EFI-бінарник, встановити непідписаний GRUB або розраховувати на ключі прошивки, яких у вашій системі немає (або вони вимкнені).

2) У чому різниця між очищенням ключів і відключенням Secure Boot?

Вимкнення Secure Boot припиняє примусову валідацію. Очищення ключів видаляє PK/KEK/db і часто переводить у режим Setup. Очищення ключів може створити напівзламаний стан; відключення — принаймні детерміноване.

3) Якщо shim підписано Microsoft, чи означає це, що Microsoft контролює моє Linux-завантаження?

Ні. Підпис Microsoft дозволяє прошивці запускати shim. Далі shim контролює наступні кроки за допомогою сертифікатів дистрибутива і/або MOK. Модель довіри залежить від ключів, які ви приймаєте у firmware db, і того, кому довіряє shim.

4) Я бачу «Secure boot enabled» і «Kernel is locked down». Це погано?

Це компроміс. Lockdown зменшує поверхню атак (плюс) і блокує деякі низькорівневі інструменти (іноді дратує). Якщо ваш робочий процес потребує таких інструментів, свідомо вирішіть, чи варто вмикати Secure Boot і lockdown на цій машині.

5) Чи можу я просто підписати GRUB сам і нічого більше не міняти?

Можете, але треба переконатися, що підписувач є довіреним для компонента, який його перевіряє. Прошивка валідує перший етап, який вона запускає; shim валідує наступний етап за вбудованими сертифікатами і MOK. Підпис без реєстрації довіри — просто дорогі біти.

6) Чому драйвер не завантажується, хоча система стартує?

Бо валідація Secure Boot на етапі завантаження й примусове підписування модулів ядра — різні рівні. Ваше ядро може бути підписане й прийняте, але DKMS-модуль може бути непідписаним і відхилений.

7) Що таке SBAT і чому він раптом зіпсував мені день?

SBAT — механізм для більш точного відкликання вразливих компонентів завантаження. Якщо ваш shim/grub занадто старі, політика SBAT може їх блокувати. Виправлення зазвичай — оновити shim/grub, а не боротися зі списком відкликання.

8) У мене dual-boot. Чи варто використовувати кастомні ключі?

Зазвичай ні, якщо тільки ви не отримуєте задоволення від управління програмою ключів у вільний час. Заводські налаштування вендора + штатний shim дистрибутива — найбільш підтримуваний підхід для dual-boot.

9) Що робити, якщо я зовсім не можу завантажитися і мені потрібно швидко повернути машину?

Завантажте live USB у режимі UEFI, змонтуйте систему й перевстановіть підписані shim/grub, як показано вище. Якщо політика дозволяє, тимчасово вимкніть Secure Boot, щоб відновити доступ, потім виправте ключі і знову увімкніть.

10) Як зрозуміти, де проблема: в db/dbx чи в MOK?

Якщо прошивка відхиляє до запуску shim — це рівень db/dbx/довіри прошивки. Якщо shim запускається, але відхиляє GRUB/ядро — це довіра shim/MOK/сертифікати дистрибутива. Якщо ОС завантажується, але модулі відмовляють, це keyring ядра/MOK і підпис модулів.

Наступні кроки, які варто виконати

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

1. Виконайте швидкі діагностичні перевірки: UEFI-завантаження, стан Secure Boot, наявність PK, ціль запису завантаження.
2. Оберіть стратегію: заводські налаштування вендора + штатний shim (в більшості випадків) або повні кастомні ключі (тільки якщо готові це обслуговувати).
3. Відновіть ланцюжок завантаження найменшими змінами: вкажіть записи на shim, перевстановіть підписані shim/grub, оновіть при SBAT/dbx-блокуваннях старі збірки.
4. Якщо потрібні DKMS-модулі — розглядайте реєстрацію MOK і підписування модулів як частину pipeline збірки, а не як нічну ритуальну операцію.
5. Запишіть, що змінили в прошивці. Майбутній ви — інша людина, і йому не варто робити сюрпризи.

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