Customized boot bios что
Если вы купили ПК или ноутбук с предустановленной операционной системой Windows 8, а потом захотели удалить ее изменить, например, “семеркой” или вообще какой-либо версий ОС Linux, то у вас возникнут с этим проблемы, из-за системы безопасной загрузки “Secure Boot”.
Разработчики компании Microsoft при разработке последней версии ОС Windows 8 полностью отказались от поддержки шестнадцати битных версий BIOS. Вместо этого система стала на 100% совместима с так называемой UEFI BIOS, обладающей системой безопасной загрузки “Secure Boot”.
Система Secure Boot предназначена для того, чтобы не позволить запуск вредоносных программ до загрузки операционной системы и антивирусного ПО соответственно.
Казалось бы, очень даже замечательная система, но, из-за Secure Boot получается попросту невозможным установить на ПК другую операционную систему или программное обеспечение, не имеющее цифровой подписи. Приведем простой пример. Вы купили новый компьютер с предустановленной Windows 8 и решили установить на него дополнительно или вместо “восьмерки” ОС Windows 7 или какую-нибудь Unix подобную систему. Можете забыть про это, функция безопасной загрузки не позволит этого сделать. Если вы не согласны с таким положением дел, то вам потребуется выполнить отключение Secure Boot в UEFI BIOS, то есть зайти в систему ввода-вывода и отключить эту назойливую систему.
Производители современных материнских плат в большинстве своем деактивируют данную функцию еще до комплектации ими устройств или поступления их в продажу. Если разработчики Unix подобных систем уже решили данную проблему в своих ОС добавив в них поддержку безопасной загрузки UEFI BIOS, то вот их коллеги из Microsoft совсем не намерены вносить изменения в Windows Vista и Windows 7. А учитывая то, что данными системами пользуется много миллионов человек, то знать, как отключить Secure Boot просто необходимо, чтобы полноценно пользоваться ПК.
Отключается Secure Boot очень просто, для этого нужно перезагрузить ПК и в самом начале его загрузки несколько раз нажать клавишу “Del” На клавиатуре (возможны другие варианты клавиши, например, F8 или F2), чтобы запустить BIOS (система ввода-вывода).
Мы не станет описывать процесс отключения Secure Boot для всех BIOS (имеется ввиду разработчиков ПО). Так как это просто не реально, да и не имеем мы пока такой возможности, чтобы под рукой были настольные и мобильные ПК всех производителей. Расскажем на примере Pheonix SecureCore Tiano, данная BIOS используется практически на всех ноутбуках, производимых компанией Samsung, а также для UEFI BIOS Utility Asus.
- Отключаем Secure Boot в ноутбуках Samsung. Перейдите в БИОС в раздел Boot. Найдите опцию Secure Boot и установите ля нее значение “Disabled”, затем установите значение “UEFI and CSM OS” для опции OS Mode Selection. Готово. Теперь вы сможете удалить Windows 8 с ноутбука Samsung и установить другую ОС.
- Отключаем Secure Boot в ноутбуках Asus. Откройте раздел UEFI “Boot”, затем “Secure Boot”, затем перейдите к опции “Key Management” и измените ее значение на “Crear Secure Boot Keys”. Готово, навязчивая функция отключена.
CSM – это модуль поддержки совместимости для операционной системы. Если ваша материнская плата снабжена отличными от описанных выше разработчиками BIOS (UEFI), то дополнительно к описанным действиям пробуйте активировать функцию Legacy BIOS.
Если после проделанных рекомендаций у вас все ровно не получается установить операционную систему отличную от Windows 8, то поэкспериментируйте с переключением SATA контролера в режим AHCI.
CSM означает Compatibility Support Module for Operating System. В других BIOS (UEFI), возможно, нужно будет включить опцию совместимости: Legacy BIOS. Если возникнут проблемы с установкой, то можно попробовать переключить SATA контроллер в режим AHCI. Как это делается написано в статье “Включаем поддержку ACHI у SATA-дисков”
UEFI (Unified Extensible Firmware Interface) — замена устаревшему BIOS. Эта спецификация была придумана Intel для Itanium, тогда она еще называлась EFI (Extensible Firmware Interface), а потом была портирована на x86, x64 и ARM. Она разительно отличается от BIOS как самой процедурой загрузки, так и способами взаимодействия с ОС. Если вы купили компьютер в 2010 году и позже, то, вероятнее всего, у вас UEFI.
Основные отличия UEFI от BIOS:
Как происходит загрузка в UEFI?
С GPT-раздела с идентификатором EF00 и файловой системой FAT32, по умолчанию грузится и запускается файл \efi\boot\boot[название архитектуры].efi, например \efi\boot\bootx64.efi
Т.е. чтобы, например, создать загрузочную флешку с Windows, достаточно просто разметить флешку в GPT, создать на ней FAT32-раздел и просто-напросто скопировать все файлы с ISO-образа. Boot-секторов больше нет, забудьте про них.
Загрузка в UEFI происходит гораздо быстрее, например, загрузка моего лаптопа с ArchLinux с нажатия кнопки питания до полностью работоспособного состояния составляет всего 30 секунд. Насколько я знаю, у Windows 8 тоже очень хорошие оптимизации скорости загрузки в UEFI-режиме.
Secure Boot
«Я слышал, что Microsoft реализовывает Secure Boot в Windows 8. Эта технология не позволяет неавторизированному коду выполняться, например, бутлоадерам, чтобы защитить пользователя от malware. И есть кампания от Free Software Foundation против Secure Boot, и многие люди были против него. Если я куплю компьютер с Windows 8, смогу ли я установить Linux или другую ОС? Или эта технология позволяет запускать только Windows?»
Начнем с того, что эту технологию придумали не в Microsoft, а она входит в спецификацию UEFI 2.2. Включенный Secure Boot не означает, что вы не сможете запустить ОС, отличную от Windows. На самом деле, сертифицированные для запуска Windows 8 компьютеры и лаптопы обязаны иметь возможность отключения Secure Boot и возможность управления ключами, так что беспокоится тут не о чем. Неотключаемый Secure Boot есть только на планшетах на ARM с предустановленной Windows!
Что дает Secure Boot? Он защищает от выполнения неподписанного кода не только на этапе загрузки, но и на этапе выполнения ОС, например, как в Windows, так и в Linux проверяются подписи драйверов/модулей ядра, таким образом, вредоносный код в режиме ядра выполнить будет нельзя. Но это справедливо только, если нет физического доступа к компьютеру, т.к., в большинстве случаев, при физическом доступе ключи можно заменить на свои.
В Secure Boot есть 2 режима: Setup и User. Первый режим служит для настройки, из него вы можете заменить PK (Platform Key, по умолчанию стоит от OEM), KEK (Key Exchange Keys), db (база разрешенных ключей) и dbx (база отозванных ключей). KEK может и не быть, и все может быть подписано PK, но так никто не делает, вроде как. PK — это главный ключ, которым подписан KEK, в свою очередь ключами из KEK (их может быть несколько) подписываются db и dbx. Чтобы можно было запустить какой-то подписанный .efi-файл из-под User-режима, он должен быть подписан ключом, который в db, и не в dbx.
Для Linux есть 2 пре-загрузчика, которые поддерживают Secure Boot: Shim и PRELoader. Они похожи, но есть небольшие нюансы.
В Shim есть 3 типа ключей: Secure Boot keys (те, которые в UEFI), Shim keys (которые можно сгенерировать самому и указать при компиляции), и MOKи (Machine Owner Key, хранятся в NVRAM). Shim не использует механизм загрузки через UEFI, поэтому загрузчик, который не поддерживает Shim и ничего не знает про MOK, не сможет выполнить код (таким образом, загрузчик gummiboot не будет работать). PRELoader, напротив, встраивает свои механизмы аутентификации в UEFI, и никаких проблем нет.
Shim зависит от MOK, т.е. бинарники должны быть изменены (подписаны) перед тем, как их выполнять. PRELoader же «запоминает» правильные бинарники, вы ему сообщаете, доверяете вы им, или нет.
Оба пре-загрузчика есть в скомпилированном виде с валидной подписью от Microsoft, поэтому менять UEFI-ключи не обязательно.
Secure Boot призван защитить от буткитов, от атак типа Evil Maid, и, по моему мнению, делает это эффективно.
Спасибо за внимание!
Как устроена загрузка современных ОС? Как при установке системы настроить загрузку посредством UEFI, не утонув в руководствах и ничего не сломав?
Я обещал "самое краткое руководство". Вот оно:
- Создаём на диске таблицу разделов GPT
- Создаём FAT32-раздел на пару сотен мегабайт
- Скачиваем из интернета любой UEFI-загрузчик
(нам нужен сам загрузчик, это один бинарный файл!) - Переименовываем и кладем этот файл на созданный раздел по адресу /EFI/Boot/bootx64.efi
- Создаём текстовый конфиг, кладем его там, где загрузчик ожидает его увидеть
(настройка и местоположение конфига зависят от конкретной реализации загрузчика, эта информация доступна в интернете) - После перезагрузки видим меню загрузчика
(Если на диске установлена Windows 8 или 10 — с большой вероятностью это руководство сокращается до пунктов 3 — 5.)
TL;DR не надо прописывать путь к загрузчику в новых загрузочных записях UEFI — надо файл загрузчика расположить по стандартному "пути по-умолчанию", где UEFI его найдет, и вместо загрузочного меню UEFI пользоваться меню загрузчика, которое гораздо проще и безопаснее настраивается
Как делать не надо
Есть, на самом-то деле, несколько способов настроить UEFI-загрузку. Я начну с описания других вариантов — чтобы было понятно, как (и почему) делать не надо. Если вы пришли за руководством — мотайте в самый низ.
Не надо лезть в NVRAM и трогать efivars
Наиболее "популярная" процедура установки загрузчика в систему такова: установщик ОС создаёт специальный раздел, на нём — структуру каталогов и размещает файлы загрузчика. После этого он с помощью особой утилиты (efibootmgr в linux, bcdedit в windows) взаимодействует с прошивкой UEFI-чипа, добавляя в неё загрузочную запись. В этой записи указывается путь к файлу загрузчика (начиная от корня файловой системы) и при необходимости — параметры. После этого в загрузочном меню компьютера появляется опция загрузки ОС. Для linux существует возможность вообще обойтись без загрузчика. В загрузочной записи указывается путь сразу к ядру вместе со всеми параметрами. Ядро должно быть скомпилировано с опцией EFISTUB (что давно является стандартом для большинства дистрибутивов), в этом случае оно содержит в себе заголовок "исполняемого файла EFI", позволяющий прошивке его запускать без внешнего загрузчика.
При старте системы, когда пользователь выбирает нужную ему загрузочную запись, прошивка UEFI сперва ищет на прописанном в этой записи диске особый EFI-раздел, обращается к файловой системе на этом разделе (обязательно FAT или FAT32), и запускает загрузчик. Загрузчик считывает из файла настроек свой конфиг, и либо грузит ОС, либо предоставляет загрузочное меню. Ничего не замечаете? Да, у нас два загрузочных меню — одно на уровне прошивки чипа UEFI, другое — на уровне загрузчика. В реальности о существовании второго пользователи могут даже не догадываться — если в меню всего один пункт, загрузчик Windows начинает его грузить без лишних вопросов. Увидеть экран с этим меню можно, если поставить вторую копию Windows или просто криво её переустановить.
Обычно для управления загрузочными записями руководства в интернете предлагают взаимодействовать с прошивкой UEFI. Есть аж пять основных вариантов, как это можно сделать: efibootmgr под linux, bcdedit в windows, какая-то софтина на "Маках", команда bcfg утилиты uefi shell (запускается из-под UEFI, "на голом железе" и без ОС, поскольку скомпилирована в том самом особом формате) и для особо качественных прошивок — графическими средствами UEFI (говоря популярным языком, "в настройках BIOS").
За всеми вышенаписанными "многобуков" вы могли легко упустить такую мысль: пользователь, чтобы изменить настройки программной части (например, добавить параметр запуска ОС), вынужден перезаписывать flash-память микросхемы на плате. Есть ли тут подводные камни? О да! Windows иногда способна сделать из ноутбука кирпич, linux тоже, причём разными способами. Качество прошивок часто оставляет желать лучшего — стандарты UEFI либо реализованы криво, либо не реализованы вообще. По логике, прошивка обязана переживать полное удаление всех переменных efivars без последствий, не хранить в них критичных для себя данных и самостоятельно восстанавливать значения по-умолчанию — просто потому что пользователь имеет к ним доступ, и вероятность их полного удаления далека от нуля. Я лично в процессе экспериментов неоднократно (к счастью, обратимо) "кирпичил" свой Lenovo — из загрузочного меню исчезали все пункты, включая опцию "зайти в настройки".
Работа с загрузочными записями UEFI — тоже не сахар. К примеру, утилита efibootmgr не имеет опции "редактировать существующую запись". Если ты хочешь немного изменить параметр ядра — ты удаляешь запись целиком и добавляешь её снова, уже измененную. При этом строка содержит в себе двойные и одинарные кавычки, а также прямые и обратные слеши в не особо очевидном порядке. Когда я наконец заставил эту магию работать — я сохранил её в виде bash-скриптов, которые до сих пор валяются у меня в корневой ФС:
Не надо использовать GRUB
Это чёртов мастодонт, 90% функциональности которого предназначено для дисков с MBR. Для настройки необходимо отредактировать ряд файлов, после чего выполнить команду генерации конфига. На выходе получается огромная малопонятная нормальному человеку простыня. В составе — гора исполняемых файлов. Ставится командой, которую просто так из головы не возьмешь — надо обязательно лезть в документацию
Для сравнения — самый простенький UEFI-bootloader, который есть в составе пакета systemd, ставится командой
Эта команда делает ровно две вещи: копирует исполняемый файл загрузчика на EFI-раздел и добавляет свою загрузочную запись в прошивку. А конфиг для неё занимает ровно СЕМЬ строчек.
"Самое краткое руководство" — чуть более подробно
Загрузочная запись нам не нужна — дело в том, что при выставлении в настройках BIOS загрузки с диска прошивка UEFI сначала ищет на нём EFI-раздел, а затем пытается исполнить файл по строго фиксированному адресу на этом разделе: /EFI/Boot/BOOTX64.EFI
Что такое "EFI-раздел"? В теории, он должен иметь особый тип "EFI System" (ef00). На практике, годится первый раздел на GPT-диске, отформатированный в FAT32 и имеющий достаточно места, чтобы разместить загрузчик и вспомогательные файлы (если есть).
Пункт 3: "Скачиваем из интернета любой UEFI-загрузчик". Что это значит? Загрузчик — это просто исполняемый файл определенного формата, к которому в комплекте идет конфиг. К примеру, если у вас есть под рукой установленный пакет с systemd — файл загрузчика можно найти по адресу /usr/lib/systemd/boot/efi/systemd-bootx64.efi, переименовать его в bootx64.efi и скопировать в /EFI/Boot/ на EFI-разделе. Нет под рукой systemd? Скачайте архив с сайта Archlinux. Или с репозитария Ubuntu. Или Debian. Есть под рукой система с Windows? Возьмите виндовый загрузчик оттуда, тоже сгодится )) Если сумеете настроить, я честно говоря не пробовал.
Пункт 4: "Настроить конфиг". Как и обычная программа, когда загрузчик запускается — он ожидает найти по определенным путям файлы конфигурации. Обычно эту информацию легко найти в интернете. Для загрузчика systemd-boot нам необходимо в корне EFI-раздела создать каталог "loader", а в нём файл "loader.conf" с тремя строчками (привожу свои):
Параметр editor отвечает за возможность отредактировать пункт загрузочного меню перед запуском.
Рядом с loader.conf необходимо создать каталог entries — один файл в нём будет отвечать за одну загрузочную запись в boot-меню. У меня там один файл arch.conf с таким содержанием:
Я не упомянул, но довольно очевидно — ядро и initramfs должны лежать в одной файловой системе с загрузчиком, то есть на EFI-разделе. Пути к ним в конфигах отсчитываются от корня этой ФС.
Другие загрузчики
systemd-boot очень простой и предоставляет спартанского вида чёрно-белое меню. Есть варианты красивей, если душа просит красоты.
Clover. Позволяет выставлять нативное разрешение экрана, имеет поддержку мыши на экране загрузки, разные темы оформления. Дефолтная тема ужасна, конфиг в виде xml нечитаем, настроить не смог.
Различные неочевидные последствия
Вы можете легко попробовать эту схему в работе. Берёте USB-флешку, форматируете в таблицу разделов GPT, создаете FAT-раздел и копируете туда загрузчик. Комп сможет с неё стартовать.
Если просто скопировать на такую флешку boot-раздел установленного linux — система будет спокойно загружаться с флешки, не видя разницы.
Компьютерные вирусы стали неотъемлемой частью нашей жизни. О них слышали даже те люди, которые сроду не пользовались компьютерами. Для улучшение защиты от зловредного ПО и был внедрен протокол Secure Boot. О том, с чем его едят и как его отключать будет подробно описано в статье.
Что такое Secure Boot (Безопасная загрузка) и когда может потребоваться ее отключение?
Secure Boot – одно из новшеств, привнесенных при внедрении UEFI. Это в свою очередь приемник БИОСа. Он, соответственно, отвечает за подготовку и загрузку ОС. BIOS можно считать очень простой утилитой с примитивным дизайном, которая прошита в материнскую плату. UEFI выполняет те же функции, но это уже весьма красивая и продвинутая программа. Например, при упорстве с помощью UEFI можно даже просматривать содержимое подключенных накопителей, что для BIOS считалось бы невероятным новшеством.
Не одними только эстетическими побуждениями руководствовались творцы UEFI. Одной из важных целей при разработке было обнаружить и ограничить влияние вредоносного ПО. Предполагалось, что технология станет препятствовать его загрузке вместе с операционной системой (ОС), а также исполнению на уровня ядра ОС после ее запуска. Честь исполнять эту важную миссию выпала на протокол Secure Boot. Техническая реализация была такой: использовалась криптографическая схема с открытыми и закрытыми сигнатурами (электронными цифровыми подписями, ЭЦП). В общем виде цели были достигнуты, но на практике это требовало определенных и правильных действий не только со стороны пользователей, но и со стороны производителей компьютерного оборудования. Описание всего процесса займет много времени, так что остановимся на ключевых особенностях:
- программные компоненты (драйвера, загрузчики ОС) имеют специальные ЭЦП, также они есть и в прошивке материнки, но характеристики этих ЭЦП отличается;
- при использовании ресурсов компьютера компоненты должны доказать при помощи ЭЦП, что они не вирусы;
- ключевой фактор безопасности – закрытый ключ, который в идеале должен быть уникальным у каждого ПК.
Сложности с технологией начались еще на этапе внедрения, когда Microsoft заявила, что с помощью протокола будет ограничивать установку других ОС на компьютеры с предустановленной Windows. Тогда от таких планов отказались под натиском общественности, но осадок остался. На сегодня основная сложность заключается в том, что производители материнских плат используют одинаковые закрытые ключи для всей своей продукции либо для отдельных линеек. В любом случае благие намерения привели к тупику.
В подавляющем большинстве случаев отключать Secure Boot стоит для решения двух проблем:
- Если не устанавливается или не загружается ОС.
- При невозможности загрузиться с загрузочной флешки.
Secure Boot сам по себе никаким образом не нагружает систему, так как работает на более низком программном уровне. Отключение протокола однозначно не улучшит отзывчивость системы и не повысит быстродействие процессора.
Как отключить защиту Secure Boot в БИОСе?
Отметим, что некоторые пользователи ошибочно думают, что протокол Secure Boot отключается в BIOS. У этой достаточно примитивной прошивки нет, не было, и не может быть поддержки СекюрБут. Этот протокол безопасности работает исключительно на UEFI и отключение нужно производить именно там. Природа этой ошибки вполне простая. За многие годы пользователи привыкли, что все, что возникает на экране до загрузки ОС это и есть БИОС. В действительности времена этой программной надстройки уходят и она уже является устарелой в любом отношении.
Примеры отключения Secure Boot на разных ноутбуках и материнских платах
Общий алгоритм всегда один и тот же:
Важно, что этот протокол безопасности поддерживается только в Windows 8 и более поздних версиях. Следовательно, если у вас в прошивке материнской платы включен Secure Boot, но на ПК установлена Windows 7, то ничего отключать не надо. Опция безопасной загрузки все равно не работает, а возможные проблемы с запуском ОС нужно искать в других местах.
Как отключить Secure Boot и UEFI на ноутбуке Acer Aspire?
Есть много моделей ноутбуков этого производителя, но специфика такова, что сначала требуется создать собственный пароль. Общий алгоритм действия следующий:
Отключение Secure Boot на ноутбуках Pavilion и других моделях HP?
- Для входа в биос жмите на ESC или ESC => F10 перед запуском Windows.
- Перейдите во вкладку “System Configuration”, а в ней отыщите строчку “Boot Options”.
- Установите для критерия “Secure Boot” опцию “Disabled”, а для критерия “Legacy support” – “Enabled”.
- Система спросит, действительно ли вы готовы изменить настройки – подтвердите это нажатием на “Yes”.
- В конце нужно сохранить выполненные изменения нажатием на F10 и подтверждением “Yes”.
При последующей перезагрузке будьте внимательны. Система перестрахуется и включит “защиту от дурака”. Нужно смотреть на то, что идет после надписи “Operating System Boot Mode Change (021)” – там будет указана цифровая последовательность. Наберите ее и нажмите Enter. Если вам нужно просто отключить Secure Boot, то дальше ничего делать не нужно. Если же изначально все делалось ради возможности загрузиться с USB-носителя, то сразу после прохождения “защиты от дурака” жмите ESC, а потом F9. Установите требуемой флешке максимальный приоритет, чтобы она грузилась первой на жесткий диск.
На ноутбуках Dell
- F12 сразу после включения компьютера и перед стартом ОС.
- В верхней панели переходите во вкладку Boot и заходите в подраздел UEFI BOOT.
- Устанавливаете для критерия “Secure Boot” опцию “Disabled”.
- Сохраняете изменения (F10 => “Yes”) и перезагружаете ноутбук.
Secure Boot на ноутбуках Леново и Тошиба
Для входа в UEFI на этих устройствах нужно жать F12, после чего выполнять следующие действия:
- перейдите во вкладку “Security”;
- установите для критерия “Secure Boot” опцию “Disabled”;
- перейдите на вкладку “Advanced”, а в ней зайдите в меню “System Configuration”;
- установите для критерия “Boot Mode (OS Mode Selection)” опцию “CSM Boot (CMS OS), (UEFI and Legacy OS)”;
- сохраните все нажатием на F10 => “Yes”.
Отключения Secure Boot на материнских платах
Рынок материнских плат для настольных компьютеров достаточно консервативен и явными лидерами являются 2 компании: Asus и Gigabyte. Они поставляют более половины всего оборудования, так что рассматривать способы деактивации Secure Boot рациональней всего именно в разрезе этих производителей. В любом случае третье и четвертое место давно оккупировали MSI и ASRock, – первая четверка полностью состоит из компаний Тайваня. Итог: принципиальных различий в инструкции по отключению все равно не будет и большая часть пользователей найдет ниже именно то, что ищет.
Отметим, что перейти сразу в UEFI можно в некоторых случаях напрямую с Windows (от 8 версии и более поздних). Для этого пробуйте следующее:
- На рабочем столе справа вызовите выдвижную панель.
- После следуйте по пути: “Параметры” => “Изменение параметров…” => “Обновление и…” => “Восстановление”;
- В возникшем окне найдите опцию перезагрузки системы и установите в этой строке значение “Настройки по UEFI” или “Параметры встроенного ПО UEFI”;
- После жмите на “Перезагрузить” и в дальнейшем должен автоматически запуститься UEFI.
Как отключить Secure Boot на материнской плате Gigabyte?
После входа в UEFI (нажатием на F12 перед запуском ОС) действуйте следующим образом:
- перейдите во вкладку “BIOS Features”;
- установите для критерия “Windows 8 Features” опцию “Other OS”;
- для критерия “Boot Mode Selection” — “Legacy only” или “UEFI and Legacy” (между ними нет особой разницы);
- для критерия “Other PCI Device ROM Priority” – “Legacy OpROM”.
После всего нужно выполнить запись изменений, то есть нажать F10 => “OK”.
Материнские платы и ноутбуки Асус
Сразу отметим, что чаще всего на материнках именно этого производителя появляется ошибка при загрузке ОС: Invalid signature detected. Check Secure Boot Policy in Setup. В большинстве случаев для устранения проблемы следует выключить Secure Boot, а для этого необходимо:
- зайти в UEFI – жмите перед загрузкой ОС на F2, Delete или комбинацию клавиш Fn+F2;
- на начальном экране жмите на F7 (Advanced Mode), а потом перейдите в меню “Boot” => “Secure Boot Menu”;
- укажите в строчке “Secure Boot State” значение “Enabled”, а в строчке “OS Type” – “Other OS”;
- вернитесь на один уровень назад в меню “Boot” => “Compatibility Support Module (CSM)”;
- установите в строчке “Launch CSM” значение “Enabled”, а в строчке “Boot Device Control” – “UEFI and Legacy …” либо “Legacy OpROM …”, а в строке “Boot From Storage Devices” – “Both Legacy opROM first”, либо “Legacy opROM first”;
- после этого жмите на F10 и сохраняйте все изменения, а после проверяйте корректность выполненных настроек.
Конкретно для ноутбуков Asus алгоритм будет следующим:
- зайдите в UEFI;
- перейдите во вкладку “Security”;
- отыщите строчку “Secure Boot Control”, укажите в ней значение “Disabled”;
- перейдите во вкладку “Boot”;
- отыщите строчку “Fast Boot”, установите в ней значение “Disabled”, а в строке “Launch CSM” значение “Enabled”.
Как узнать активирована ли функция Secure Boot на Windows?
Этот протокол несложно активировать и деактивировать, а для понимания текущего статуса есть несколько проверенных подходов:
Заключение
- Secure Boot появился в компьютерном мире относительно недавно и этот протокол безопасности является составляющей UEFI – современным и актуальным видом прошивки материнских плат.
- Протокол безопасности препятствует запуску вредоносного ПО на более низком уровне, чем это делают обычные антивирусы. Поэтому при правильной настройке эта технология может существенно повысить устойчивость ПК к вирусам.
- Secure Boot стоит отключать по необходимости, если он препятствует старту системы с загрузочной флешки или при переустановке Windows. Просто для эксперимента технологию деактивировать не стоит.
- Для любого компьютера схема деактивации одна и та же – за счет указания подходящего критерия в нужном меню UEFI. Главное – это найти правильный путь к такому меню. Даже при существенных сложностях это займет не больше 10 минут.
Данные обещания надо выполнять, тем более, если они сделаны сначала в заключительной части опуса о безопасности UEFI, а потом повторены со сцены ZeroNights 2015, поэтому сегодня поговорим о том, как заставить UEFI SecureBoot работать не на благо Microsoft, как это чаще всего настроено по умолчанию, а на благо нас с вами.
Если вам интересно, как сгенерировать свои собственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.
Введение
С ликбезом закончили, теперь к делу. Несмотря на то, что про создание своих ключей и настройку SecureBoot написано за три последних года с десяток отличных статей (ссылки на часть из которых приведены в разделе Литература), воз и ныне там. Основная проблема с информацией о настройке SecureBoot даже в англоязычном сегменте сети (не говоря уже о рунете) — большая часть статей, текстов и постов обрывается на «вот у нас теперь есть ключи в формате EFI Signature List, добавьте их зависимым от вашего вендора прошивки способом и готово». При этом сами вендоры не торопятся описывать меню настройки SecureBoot ни в документации на свои платформы для OEM'ов, ни в мануалах на конечные системы, в результате пользователь теряется на незнакомой местности и либо отключает SecureBoot, мешающий загружать его любимую OpenBSD (или что там у него), либо оставляет его на настройках по умолчанию (а чего, Windows грузится же). Именно этот последний шаг я и попытаюсь описать более подробно, но не в ущерб остальным необходимым шагам.
Тестовая конфигурация
Специально для этой статьи я достал из закромов пару не самых новых ноутбуков с прошивками на платформах Phoenix SCT и Insyde H2O, а также совершенно новую плату congatec (разработкой прошивки для которой я занят в данный момент) на платформе AMI AptioV. Встречайте, наши тестовые стенды:
1. AMI, они же "треугольные": congatec conga-TR3 @ conga-TEVAL, AMD RX-216GD (Merlin Falcon), AMI AptioV (UEFI 2.4)
2. Insyde, они же "квадратные": Acer Aspire R14 R3-471T (Quanta ZQX), Intel Core i3-4030U (Ivy Bridge), Insyde H2O (UEFI 2.3.1C)
3. Phoenix, они же "полукруглые": Dell Vostro 3360 (Quanta V07), Intel Core i7-3537U (Ivy Bridge), Phoenix SCT (UEFI 2.3.1C)
Об интерфейсах для настройки SecureBoot
На всех вышеперечисленных системах производитель заявляет о поддержке технологии UEFI SecureBoot, но интерфейс для ее настройки сильно отличается между системами. К счастью, это не очень большая проблема, поскольку для настройки SecureBoot на совместимых со спецификацией UEFI 2.3.1C (и более новых) прошивках никакого интерфейса в Setup, кроме возможности удаления текущего PK (т.е. перевода SecureBoot в так называемый Setup Mode) не требуется, а после этого можно использовать любое EFI-приложение, способное вызвать UEFI-сервис gRS->SetVariable с предоставленными пользователем данными, в том числе утилиту KeyTool.efi из пакета efitools, которая специально для управления ключами и предназначена, осталось только научиться ей пользоваться.
Тем не менее, если удобный интерфейс для настройки присутствует (у AMI он, на мой взгляд, даже удобнее KeyTool'а) — можно воспользоваться им, так что рассказывать про эти самые интерфейсы все равно придется.
Готовим плацдарм
Начнем с лирического отступления о наличии нужного софта для разных ОС. Несмотря на то, что Microsoft является одним из разработчиков технологии, в открытом доступе до сих пор отсутствуют нормальные средства для работы с ней из Windows (ключи можно сгенерировать утилитой MakeCert из Windows SDK, а для всего остального предлагается использовать HSM третьих лиц за большие деньги). Я подумывал сначала взять и написать нужную утилиту на Qt, но потому решил, что ключи и подписи каждый день генерировать не нужно, а на пару раз хватит и существующих решений. Можете попробовать переубедить меня в комментариях, если хотите.
В общем, для всего нижеперечисленного вам понадобится Linux (который можно запустить с LiveUSB, если он у вас не установлен). Для него существует целых два набора утилит для работы с SecureBoot: efitools/sbsigntool и EFIKeyGen/pesign. У меня есть положительный опыт работы с первым набором, поэтому речь пойдет именно о нем.
В итоге, кроме Linux, нам понадобятся несколько вещей:
1. Пакет openssl и одноименная утилита из него для генерирования ключевых пар и преобразования сертификатов из DER в PEM.
2. Пакет efitools, а точнее утилиты cert-to-efi-sig-list, sign-efi-sig-list для преобразования сертификатов в формат ESL и подписи файлов в этом формате, и KeyTool.efi для управления ключами системы, находящейся в SetupMode.
3. Пакет sbsigntool, а точнее утилита sbsign для подписи исполняемых файлов UEFI (т.е. загрузчиков, DXE-драйверов, OptionROM'ов и приложений для UEFI Shell) вашим ключом.
Загрузите Linux, установите вышеуказанные пакеты, откройте терминал в домашней директории и переходите к следующему шагу.
Генерируем собственные ключи для SecureBoot
Как обычно, есть несколько способов сделать что-либо, и чем мощнее используемый инструмент, тем таких способов больше. OpenSSL же как инструмент развит настолько, что кажется, что он умеет делать вообще всё, а если почитать к нему man — то и абсолютно всё остальное. Поэтому в этой статье я ограничусь непосредственной генерацией ключевых файлов, а танцы вокруг создания собственного CA оставлю на самостоятельное изучение.
Генерируем ключевые пары
Конвертируем открытые ключи в формат ESL
Теперь нужно сконвертировать открытые ключи из формата PEM в понятный UEFI SecureBoot формат ESL. Этот бинарный формат описан в спецификации UEFI (раздел 30.4.1 в текущей версии 2.5) и интересен тем, что файлы в нем можно соединять друг с другом конкатенацией, и этот факт нам еще пригодится.
Ключ -g добавляет к сгенерированному ESL-файлу GUID, в нашем случае — случайный, полученый запуском утилиты uuidgen и использованием ее вывода. Если этой утилиты у вас нет — придумывайте GUIDы сами или оставьте значение по умолчанию.
Подписываем ESL-файлы
Для правильно работы SecureBoot необходимо, чтобы PK был подписан сам собой, KEK подписан PK, а хранилища db и dbx — сответственно KEK. При этом PK не может быть несколько, а вот ситуация с несколькими KEK хоть и встречается в дикой природе, но я все же настоятельно рекомендую удалить предустановленный ключ Microsoft из KEK по простой причине — db и dbx могут быть подписаны любым ключом из хранилища KEK, т.е. если ключ MS оттуда не удалить, то у MS будет возможность управлять содержимым db и dbx, т.е. добавлять любые новые ключи или хеши в список доверенной загрузки и удалять из него существующие. На мой взгляд, это немного слишком, и если мы берем управление ключами в свои руки, то нужно делать это до конца.
Ну тогда вам прямая дорога вот сюда, там в самом конце раздела 1.3.4.3 есть ссылка на сертификат Microsoft Corporation KEK CA 2011 в формате DER, из которого нужно сначала получить PEM командой
затем сконвертировать полученный PEM в ESL командой
после чего добавить получившийся файл к нашему файлу KEK.esl командой
Теперь Microsoft такой же авторизованный пользователь вашей платформы, как и вы сами, с чем я вас и поздравляю.
С другой стороны, если вы не хотите терять возможность загрузки Windows и подписанных ключом Microsoft исполняемых компонентов (к примеру, GOP-драйверов внешних видеокарт и PXE-драйверов внешних сетевых карточек), то к нашему ISK.esl надо будет добавить еще пару ключей — ключ Microsoft Windows Production CA 2011, которым MS подписывает собственные загрузчики и ключ Microsoft UEFI driver signing CA, которым подписываются компоненты третьих сторон (именно им, кстати, подписан загрузчик Shim, с помощью которого теперь стартуют разные дистрибутивы Linux, поддерживающие SecureBoot из коробки).
Последовательность та же, что и под спойлером выше. Конвертируем из DER в PEM, затем из PEM в ESL, затем добавляем к db.esl, который в конце концов надо будет подписать любым ключом из KEK:
Теперь подписываем PK самим собой:
Подписываем KEK.esl ключом PK:
Подписываем db.esl ключом KEK:
Если еще не надоело, можно добавить чего-нибудь еще в db или создать хранилище dbx, нужные команды вы теперь знаете, все дальнейшее — на ваше усмотрение.
Подписываем загрузчик
Осталось подписать какой-нибудь исполняемый файл ключом ISK, чтобы проверить работу SecureBoot после добавления ваших ключей. Для тестов я советую подписать утилиту RU.efi, она графическая и яркая, и даже издалека видно, запустилась она или нет. На самом деле, утилита эта чрезвычайно мощная и ей можно натворить немало добрых и не очень дел, поэтому после тестов лучше всего будет её удалить, и в дальнейшем подписывать только загрузчики.
В любом случае, подписываются исполняемые файлы вот такой командой:
Здесь я заодно переименовал исполняемый файл в bootx64.efi, который нужно положить в директорию /EFI/BOOT тестового USB-носителя с ФС FAT32. Для 32-битных UEFI (избавь вас рандом от работы с ними) используйте bootia32.efi и RU32.efi.
В результате вот этого всего у вас получились три файла .auth, которые нужно будет записать «как есть» в NVRAM-переменные db, KEK и PK, причем именно в таком порядке. Скопируйте все три файла в корень другого USB-носителя с ФС FAT32, на котором в качестве /EFI/BOOT/bootx64.efi выступит /usr/share/efitools/efi/KeyTool.efi (скопируйте его еще и в корень, на всякий случай) и ваш «набор укротителя SecureBoot» готов.
Укрощение строптивого
AMI AptioV
Insyde H2O
Phoenix SCT
Здесь возможностей еще меньше, и во всем меню Secure Boot Configuration на вкладке Security всего два пункта: возврат к стандартным ключам и удаление всех ключей с переводом системы в SetupMode, нам нужно как раз второе:
Затем на вкладке Boot нужно выбрать тип загрузки UEFI, включить SecureBoot, и создать загрузочную запись для KeyTool'а, иначе на этой платформе его запустить не получится:
Нажимаем Yes, выходим с сохранением изменений, перезагружаемся, нажимаем при загрузке F12, чтобы попасть в загрузочное меню, оттуда выбираем KeyTool, работа с которым описана выше. После добавления ключей и перезагрузки попытка повторного запуска KeyTool'а заканчивается вот так:
При этом установленный на той же машине Linux продолжает исправно загружаться, как и подписанная нами RU.efi, так что SecureBoot можно признать работоспособным.
Заключение
В итоге, благодаря утилитам с открытым кодом, удалось завести SecureBoot на системах с UEFI трех различных вендоров, сгенерировать свои собственные ключи и подписать ими нужные нам исполняемые файлы. Теперь загрузка платформы целиком в наших руках, но только в случае, если пароль на BIOS стойкий и не хранится открытым текстом, как у некоторых, а в реализации SecureBoot нет каких-либо известных (или еще неизвестных) дыр. Сам по себе SecureBoot — не панацея от буткитов, но с ним ситуация с безопасной загрузкой все равно намного лучше, чем без него.
Надеюсь, что материал вам поможет, и спасибо за то, что прочитали эту портянку.
Читайте также: