Secure Boot: что даёт и почему часто мешает

Введение

Secure Boot — один из самых спорных и в то же время важных механизмов безопасности, появившихся с распространением UEFI.
Его цель звучит просто: предотвратить запуск неподписанного или поддельного загрузочного кода, то есть защитить систему до того момента, как ядро ОС успеет заработать и включить собственные средства защиты.

Однако на практике Secure Boot часто становится источником проблем:
– Linux не загружается;
– Windows сообщает “Security violation”;
– загрузчик GRUB перестаёт работать после обновления;
– кастомные ядра блокируются;
– восстановление загрузки требует временного отключения механизма;
– запись NVRAM исчезает, но Secure Boot продолжает блокировать попытки запуска альтернативных загрузчиков.

Чтобы понять, почему так происходит, нужно разобраться как именно устроен Secure Boot “под капотом”, как он принимает решения и почему иногда отказывает в загрузке даже корректным файлам.

Эта статья — полный разбор механизма: архитектура, криптография, последовательность проверки, взаимодействие с Windows/Linux, типичные ошибки и сценарии восстановления.

---

1. История появления Secure Boot

Появление Secure Boot было связано с ростом вредоносных программ, которые внедряются в цепочку загрузки:

• bootkit — модифицирует загрузчик;

• rootkit — внедряется в ядро на раннем этапе;

• MBR-вирусы — заменяют первый сектор диска;

• LOADER-инжекторы — подменяют EFI-файлы.

Главная проблема — такие программы запускаются раньше антивируса, и их сложно обнаружить.

В 2011–2012 годах Microsoft предложила производителям ПК использовать UEFI и включить механизм Secure Boot по умолчанию, чтобы:

1. загрузчик был подписан доверенным сертификатом;

2. изменение EFI-раздела блокировалось;

3. никто не мог подменить Boot Manager без ведома пользователя.

На бумаге идея проста, но реализация оказалась более сложной и привела к множеству конфликтов с Linux и кастомными ОС.

---

2. Архитектура ключей Secure Boot

Secure Boot сравнивает цифровые подписи файлов с “хранилищем доверенных ключей”. Оно состоит из нескольких уровней:

PK (Platform Key)
Главный ключ платформы.
Позволяет подтверждать изменения всех остальных ключей.
Его изменяют только производители или продвинутые пользователи.

KEK (Key Exchange Key)
Ключи, которые могут обновлять списки доверенных загрузчиков.
Microsoft имеет KEK, поэтому Windows может обновлять свой Boot Manager.

db (Signature Database)
База доверенных сертификатов и хэшей.
Если подпись файла есть в db — его можно запускать.

dbx (Forbidden Signatures Database)
“Чёрный список” загрузчиков.
Если загрузчик обнаружен в dbx — он блокируется, даже если подписан Microsoft.

Это объясняет распространённую проблему:
иногда старые версии GRUB попадают в dbx из-за уязвимостей, и Secure Boot блокирует их, даже если Linux установлен корректно.

---

3. Как Secure Boot выполняет проверку

Последовательность проверки всегда одна и та же:

1. UEFI читает NVRAM и ищет загрузчик, который должен быть запущен.

2. Находит файл в EFI-разделе, например:

   • EFI/Boot/bootx64.efi

   • EFI/Microsoft/Boot/bootmgfw.efi

   • EFI/ubuntu/shimx64.efi

3. Извлекает подпись файла (PKCS#7).

4. Проверяет подпись по списку ключей db.

5. Проверяет, не находится ли файл в dbx.

6. Если проверка успешна — загрузка продолжается.

7. Если нет — появляется ошибка Security Violation.

Важно: Secure Boot не знает про ядро ОС.
Он проверяет только:

• shim (в Linux);

• GRUB;

• Windows Boot Manager;

• любые .efi-файлы, которые участвуют в цепочке.

---

4. Secure Boot и Windows

Windows использует Boot Manager bootmgfw.efi, который подписан Microsoft KEK.
Обычно он не вызывает проблем, но есть исключения:

Проблема 1. Повреждение EFI-раздела

Если файлы Windows переименованы или повреждены, Secure Boot блокирует загрузку.

Проблема 2. Удаление старых версий Boot Manager

Обновления Windows могут очищать NVRAM-записи.

Проблема 3. Флешки, созданные Rufus

Некоторые версии Rufus создают альтернативный Boot Manager для обхода Secure Boot, что вызывает конфликт.

---

5. Secure Boot и Linux

Linux не подписывает ядро Microsoft KEK. Поэтому придумано решение:

shim → grub → kernel

Shim — маленький загрузчик, подписанный Microsoft.
Его задача — гарантировать, что GRUB и ядро тоже доверенные.

Но:

• если shim устарел

• или подпись GRUB изменилась

• или dbx добавил GRUB в “чёрный список”
  — Linux перестаёт загружаться.

Особенно часто такое случается с дистрибутивами:

• Arch Linux

• Gentoo

• Debian (старые версии)

• Manjaro

Ubuntu и Fedora обновляют shim чаще, поэтому проблем меньше.

6. Почему Secure Boot так часто создаёт проблемы

Secure Boot — не просто «защитный флажок». Это механизм, который вмешивается в один из самых чувствительных процессов — раннюю фазу загрузки, когда ОС ещё не работает.

Если что-то не совпадает:

• версия сертификата;

• структура EFI-раздела;

• подпись shim/GRUB;

• изменения в db/dbx;

• конфликт ключей;

• несовместимость с кастомной сборкой Linux…

…Secure Boot блокирует запуск, потому что не может гарантировать, что код безопасен.

В итоге даже небольшие изменения в EFI-разделе могут привести к полной потере загрузки.

---

7. Типичные ошибки Secure Boot

Ошибка 1: “Security Violation”

Означает, что файл .efi не проходит проверку подписи.

Причины:

• повреждён shim;

• устаревшая версия GRUB;

• неподписанное ядро;

• загрузчик в списке dbx;

• замена файла вручную.

В Linux особенно часто встречается, если пользователь пытался обновить GRUB вручную.

---

Ошибка 2: “Verification Failed”

Эта ошибка связана с подписями элементов цепочки shim → grub → kernel.

Типичная причина:
shimx64.efi подписан Microsoft, а grubx64.efi — нет.

Решение:
обновить shim и GRUB до версий, совместимых с Secure Boot (обычно Fedora/Ubuntu уже имеют такие сборки).

---

Ошибка 3: “Invalid Signature” при загрузке Windows

Редкая, но встречается, когда:

• повреждены файлы Boot Manager;

• обновление Windows создало новый Boot Manager, но старый остался в NVRAM;

• включён CSM, а Windows ожидает UEFI.

Secure Boot воспринимает это как попытку запуска неподписанного кода.

---

Ошибка 4: Чёрный экран без сообщений

Secure Boot иногда просто прекращает выполнение, даже не показывая предупреждений.

Причины:

• чёрный список dbx блокирует shim;

• не совпадает хэш загрузчика;

• проблема с протоколом GOP (старые видеокарты);

• конфликты между UEFI ROM на видеокарте и встроенным UEFI.

---

Ошибка 5: “Boot failed” при загрузке с флешки

Очень распространено на ноутбуках Lenovo и HP:

Почему?

Потому что флешка содержит не подписанный загрузчик, например:

• Ventoy

• Rufus с режимом Non-UEFI

• Linux-образ без shim

• кастомные сборки Windows PE

Secure Boot блокирует запуск таких флешек.

---

8. Secure Boot и Linux: почему проблемы возникают чаще, чем в Windows

У Windows один загрузчик — один набор ключей — один производитель.
У Linux — десятки дистрибутивов, сотни версий ядер, тысячи вариантов конфигурации GRUB.

Основные причины сбоев Linux:

1) Несовпадение версий shim и GRUB

Если shim новый, а GRUB старый — они конфликтуют.

2) GRUB или ядро подписаны неподходящим сертификатом

Часто встречается в Arch, Gentoo, Manjaro.

3) dbx добавил в чёрный список определённые версии загрузчиков

Microsoft периодически обновляет dbx, блокируя уязвимые версии GRUB.

Например, была история, когда целый ряд версий GRUB оказался в dbx.
Тысячи машин перестали грузить Linux после обновлений UEFI.

4) Ядро было перекомпилировано пользователем

Такое ядро всегда блокируется Secure Boot.

5) Сломан EFI-раздел

GRUB пытается обратиться к файлам, которых нет.

6) Менялась разметка диска (LVM, BTRFS)

Secure Boot не позволяет GRUB читать конфигурации, если они не совпадают с ожидаемыми.

---

9. Secure Boot и Windows: менее частые, но критические ошибки

Windows более стабильна благодаря подписанному Boot Manager, но проблемы тоже бывают.

1) Обновление BIOS

После перепрошивки BIOS:

• сбрасываются ключи;

• меняется Secure Boot Mode;

• удаляются загрузочные записи.

Windows перестаёт загружаться, хотя EFI-раздел в порядке.

2) Обновления Windows

Особенно крупных версий:

• создают новый Boot Manager;

• перемещают файлы;

• старый загрузчик остаётся в NVRAM;

• новый не добавляется.

Secure Boot блокирует несовпадение записей.

3) Вмешательство сторонних программ

Некоторые программы для “восстановления системы” изменяют EFI-раздел:

• AOMEI

• Paragon

• старые версии Acronis

• Hiren’s 2016–2019

Secure Boot сразу блокирует такие изменения.

4) Неправильное восстановление bootrec

Команда:

на новых системах может создавать загрузчик, несовместимый с текущей конфигурацией Secure Boot.

---

10. Почему флешки не загружаются при включённом Secure Boot

Secure Boot не доверяет:

• неподписанным загрузчикам;

• кастомным EFI-файлам;

• устаревшим shim;

• WinPE без подписи;

• Ventoy без Secure Boot Mode;

• Linux-образам, содержащим только GRUB.

Самые частые случаи:

1. Ventoy

Ventoy работает через собственный загрузчик → Secure Boot его блокирует.

Есть режим Secure Boot Support, но он работает нестабильно.

---

2. Rufus (MBR + BIOS)

Если флешка записана в режиме BIOS/MBR — UEFI с Secure Boot её не запустит.

---

3. Windows PE

Пользовательские PE-образцы почти всегда не подписаны.

---

4. Сборки Linux “для ремонта”

Большинство LiveCD не содержат подписанного shim.

---

5. Старые ISO Windows 7/8

Secure Boot не поддерживает Windows 7 вообще.

---

11. Когда Secure Boot стоит отключить

Secure Boot рекомендуется отключить в таких ситуациях:

• установка Linux;

• использование нестандартных сборок Windows;

• восстановление EFI-раздела;

• диагностика загрузки;

• восстановление GRUB;

• переключение режимов UEFI/Legacy;

• работа с Ventoy или WinPE;

• необходимость загрузки с “подозрительных” флешек;

• использование тестовых сборок ядра.

---

12. Когда Secure Boot обязательно нужен

Несмотря на проблемы, Secure Boot полезен в:

• корпоративных ноутбуках;

• системах с высоким уровнем доверия;

• учебных заведениях, где пользователи часто портят загрузчики;

• государственных организациях;

• терминалах самообслуживания;

• защищённых серверах.

Secure Boot предотвращает внедрение:

• bootkit;

• MBR-вирусов;

• подменённых GRUB;

• вредоносных Boot Manager.

13. Полный алгоритм диагностики при ошибках Secure Boot

Этот алгоритм помогает быстро определить, на каком этапе возникает проблема и что именно нужно чинить.

---

Шаг 1. Проверить режим загрузки UEFI/Legacy

Secure Boot работает только в UEFI. Если включён CSM — механизм ведёт себя нестабильно.

Порядок проверки:

1. Перейти в BIOS → вкладка Boot

2. Убедиться, что:

   • Boot Mode = UEFI

   • CSM = Disabled

   • Secure Boot = Enabled (на время диагностики можно отключить)

Если в этот момент система начинает грузиться — проблема не в EFI-разделе, а в конфликте режима загрузки.

---

Шаг 2. Проверка состояния Secure Boot Mode

Есть два состояния:

• Standard Mode — все ключи производителя действуют

• Setup Mode — ключи сброшены; Secure Boot фактически выключен

Если Secure Boot завис в Setup Mode, он может блокировать запуск любых загрузчиков.

---

Шаг 3. Проверка записи в NVRAM

В Linux:

Если загрузчик Windows или Linux отсутствует в списке, его нужно пересоздать.

В Windows проверить можно так:

Если вывод пустой — запись NVRAM утеряна.

---

Шаг 4. Проверить EFI-раздел на ошибки

EFI-раздел должен быть:

• FAT32

• Размера 100–500 МБ

• И содержать папки вида:

Если файлов нет — BOOTMGR или GRUB не будут обнаружены.

---

Шаг 5. Проверить подпись shim/GRUB/Boot Manager

Если файл был заменён вручную, изменён или повреждён — Secure Boot заблокирует его.

Проверка в Linux:

---

Шаг 6. Проверить, не попал ли загрузчик в чёрный список dbx

Microsoft регулярно обновляет dbx, блокируя уязвимые версии GRUB.

Проверить:

Если версия GRUB в списке — загрузка невозможна, нужно обновление shim.

---

Шаг 7. Проверить USB-носитель

Флешки на Ventoy, WinPE, старых ISO всегда блокируются Secure Boot.

Если USB — причина, система загрузится только:

• с отключённым Secure Boot

• или через подписанный загрузчик (Red Hat, Ubuntu UEFI)

---

14. Восстановление загрузки Linux при ошибках Secure Boot

Сценарий A: Linux перестал грузиться после обновления GRUB

1. Загрузиться с LiveCD Ubuntu/Fedora (они подписаны Microsoft)

2. Смонтировать систему:

3. Переустановить shim/GRUB:

или

4. Проверить подписи:

5. Пересоздать запись в NVRAM:

---

Сценарий B: Secure Boot блокирует ядро (kernel)

Причина: ядро неподписано или подписано неподходящим ключом.

Решения:

Вариант 1: использовать подписанное ядро от дистрибутива

Например, linux-image-generic в Ubuntu.

Вариант 2: подписать ядро вручную

(редко используется, но возможно)

---

Сценарий C: shim устарел и попал в dbx

Решение: установить новую версию shim от дистрибутива.

Ubuntu:

Fedora:

---

15. Восстановление Windows Boot Manager при включённом Secure Boot

Сценарий A: повреждён EFI-раздел

Загружаемся в WinRE → Командная строка.

1. Формируем новый EFI-раздел

(если старый уничтожен)

2. Воссоздаём загрузчик

3. Проверяем запись NVRAM

---

Сценарий B: Secure Boot блокирует старый Boot Manager

Иногда старые версии Boot Manager после обновлений попадают в dbx.

Решение:

Это создаст новый подписанный загрузчик.

---

Сценарий C: конфликт режимов CSM/UEFI

Если Windows была установлена в UEFI, включение CSM делает её незагружаемой.

Исправляется:

1. Выключить CSM

2. Включить Secure Boot (или оставить выключенным)

3. Проверить EFI-раздел

---

16. Как восстановить NVRAM

Linux

Windows

Полный сброс NVRAM

В BIOS:

---

17. Как проверить целостность EFI-раздела

Linux

Windows

Типовые проблемы:

• пустой EFI-раздел;

• повреждение FAT32;

• пропавший каталог Microsoft;

• лишние каталоги после утилит Acronis/PXE.

---

18. Как исправить чёрный список dbx

Иногда нужный загрузчик блокирован dbx.
Решение — установка обновлённого дистрибутива shim или восстановление ключей вручную.

Показать dbx:

Если ключ там — обновляешь shim.

---

19. Таблица быстрых решений

---

20. Выводы и рекомендации

Secure Boot — мощный механизм защиты, но он требует понимания архитектуры загрузки.
В большинстве случаев проблемы возникают из-за:

• повреждённого EFI-раздела;

• устаревшего shim;

• конфликтов GRUB;

• неправильной настройки режима загрузки;

• неподписанных флешек;

• обновлений BIOS/Windows.

Для стабильной работы:

• обновляйте BIOS аккуратно;

• используйте официальные ISO с поддержкой Secure Boot;

• избегайте кастомных WinPE/LiveCD;

• не смешивайте CSM и UEFI;

• не трогайте EFI-раздел вручную.