Efi optimized boot в серверных материнских платах что это
Что происходит при запуске сервера, порой неизвестно даже опытным системным администраторам и разработчикам. Во второй части материала тестировщик Selectel, Владимир Туров, подробно рассказывает о процессе на примере UEFI.
Первая версия того, что сейчас известно как Unified Extensive Firmware Interface (UEFI), разрабатывалась в 90-е годы прошлого тысячелетия специально под системы на Intel® Itanium® и называлась Intel Boot Initiative, а позже — EFI.
Желание «обновить» процесс загрузки было ожидаемо. PC-BIOS, именуемый ныне Legacy, предлагает работать в 16-битном real mode, адресует всего 1 МБ оперативной памяти, а загрузчик вместе с таблицей разделов должен размещаться в первых 512 байтах накопителя. Более того, PC-BIOS передает управление первому найденному загрузчику без возможности возврата назад. При этом обработку случаев с несколькими операционными системами возлагают на плечи загрузчика.
Ограничение на размер загрузчика диктует использование разметки Master Boot Record (MBR), появившийся в 1983 году. MBR не стандартизирован, однако множество производителей придерживаются «сложившихся традиций». У MBR есть серьезные ограничения: по умолчанию поддерживается только 4 раздела и объем накопителя не более 2.2 ТБ.
В декабре 2000 года была выпущена первая широко распространенная спецификация EFI под версией 1.02. Спустя пять лет Intel передали EFI в UEFI Forum, добавив Unified в название, чтобы подчеркнуть изменения. Спецификация UEFI лежит в открытом доступе и состоит из нескольких документов:
- ACPI Specification;
- UEFI Specification;
- UEFI Shell Specification;
- UEFI Platform Initialization Specification;
- UEFI Platform Initialization Distribution Packaging Specification.
Самое интересное начинается в UEFI Platform Initialization Specification, где описываются все фазы загрузки платформы.
UEFI универсален, но в данной статье мы будем опираться на стандарт, поглядывая в сторону процессоров на архитектуре x86_64.
Последовательность фаз загрузки UEFI Источник: UEFI Platform Initialization SpecificationПосле инициации включения платформы блок питания ждет, пока не завершатся переходные процессы, и после устанавливает сигнал на линию Power_Good. И первым начинает работу не центральный процессор, а автономная подсистема Intel® Management Engine (ME) или аналогичная ей AMD Secure Technology (ST). Эта подсистема проводит собственные операции, а затем подготавливает и запускает первое ядро одного процессора, именуемое Bootstrap Processor (BSP).
В соответствии с принятой терминологией ядро/поток процессора здесь и далее будет называться процессором: начальным (bootstrap processor) или прикладным (application processor).
Как и в Legacy, процессор начинает выполнять первую инструкцию в конце адресного пространства по адресу 0xfffffff0. Эта инструкция — прыжок на первую фазу инициализации платформы — SEC.
- обработка события включения;
- инициализация достаточного количества памяти для следующей фазы;
- становление корня доверия системы;
- передача необходимой информации и управления на следующую фазу.
Процессоры x86_64 запускаются в 16-битном реальном режиме, и в процессе первичной инициализации BSP переводится в 32-битный защищенный режим. Затем происходит обновление микрокода всех доступных процессоров.
Следом происходит обработка события включения. Под этим подразумевается агрегация информации о состояниях оборудования, чтобы на следующей фазе некоторые модули могли сделать выводы о «здоровье» и общем состоянии платформы.
Во время фазы SEC не происходит инициализация оперативной памяти. Вместо этого свободный кэш процессора помечается как несбрасываемый, и он превращается во временную оперативную память. Такой режим называется no-eviction mode (NEM). В выделенной памяти создается стек, что позволит модулям из следующих фаз использовать стековые языки программирования до инициализации основной оперативной памяти.
Далее происходит инициализация всех прикладных процессоров (Application Processor, AP) с отправкой им специальной последовательности межпроцессорных прерываний (Inter-Processor Interrupt, IPI). Последовательность Init IPI — Start-up IPI — пробуждает прикладной процессор и запускает на нем самотестирование — Built-In Self-Test (BIST). Результаты тестирования записываются и передаются далее для анализа.
В конце фазы Security необходимо найти раздел Boot Firmware Volume (BFV), на котором располагается исполняемый код следующей фазы, а также по возможности найти другие, неосновные, разделы с кодом (Firmware Volume, FV).
Чтобы оправдать название фазы Security и стать корнем доверия, во время выполнения этой фазы код, которому мы планируем передать управление, может быть проверен на отсутствие несанкционированных изменений и вредоносных частей программы.
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 — система будет спокойно загружаться с флешки, не видя разницы.
Замена Legacy BIOS на расширяемый интерфейс фирменного программного обеспечения, больше известный как UEFI, произошла быстро и безболезненно. В этом нет ничего удивительного – несколько секунд старта компьютера или ноутбука – капля в море времени, которое пользователи тратят на работу с приложениями в операционных системах. О старте будут говорить только в том случае, если он не состоялся. Давайте рассмотрим технологии, которые стоят на страже спокойствия пользователей: что обеспечивает совместимость UEFI в условиях замены устаревших концепций более новыми?
Технология совместимости
С появлением UEFI программный код Option ROM (или другими словами BIOS периферийных устройств) становится таким же артефактом, как и Legacy BIOS. Так, на смену VGA BIOS приходит Graphics Output Protocol (GOP), а встроенный BIOS других контроллеров заменяется аналогичными решениями из мира UEFI. Но, в отличие от системного BIOS, низкоуровневое программное обеспечение периферии не подвластно производителям вычислительных платформ. Это значит, что необходимо обеспечить совместимость UEFI-систем с устаревшим оборудованием.
На решение этой задачи нацелена технология Compatibility Support Module (CSM). Компатибильность здесь ключевое понятие. Как IT-индустрия приходила к пониманию этого процесса? Рассмотрим состав Aptio Setup Utility трехлетней давности. Версия v2.00 еще не отражает в полной мере все подробности совместимости, где за строкой меню EFI Optimized Boot скрывается работа именно CSM-модулей.
Рис 1. Скриншот меню Aptio Setup Utility v2.00.1201 на системной плате Intel S1200BT
Обратите внимание, что параметр Use Legacy Video for EFI OS недоступен для редактирования, в отличие от соседних пунктов меню Boot Option Retry и USB Boot Priority. В отсутствие GOP-совместимых видеоадаптеров на серверной платформе Intel S1200BT по умолчанию используется VGA BIOS, обслуживающий бортовое видео на дискретном чипе. Хотя такое аппаратное решение и не препятствует использованию программного кода, написанного по правилам Graphics Output протокола.
Запуск оболочки UEFI Shell в перечне доступных опций выглядит тенденцией, на годы опередившей время. К сожалению, по неизвестным до сих пор причинам именно эта функциональность остается невостребованной производителями компьютерной техники.
Рис 2. Скриншот меню Aptio Setup Utility v2.00.1201 на системной плате ASUS Z87-K
Новая версия Aptio v2.10, установленная на системной плате ASUS Z87-K, дает более полное представление о функциональности Compatibility Support Module. Активация опции меню Launch CSM приводит к появлению четырех дополнительных параметров, каждый из которых балансирует между новаторством UEFI и совместимостью с Option ROM.
Рис 3. Выбор устройств для запуска операционной системы:UEFI-совместимая загрузки или использование Option ROM
Последний писк
Наиболее полный подход к управлению совместимостью демонстрирует American Megatrends, разработчик низкоуровневого программного обеспечения, в Aptio v2.15 (датирование прошлым годом добавляет драйва :). Эта версия Setup Utility была обнаружена на серверной плате Tyan S7052 (снимок анбоксинга в заголовке статьи).
Рис 4. Boot-меню в Aptio Setup Utility на серверной платформе S7052GM3NR
Логика управления периферийными устройствами отражает все аспекты использования CSM-технологии: для видео адаптеров выделено отдельное меню, сетевые Boot ROM и OpROM систем хранения данных — на своих местах. Все прочие PCI-устройства вынесены в отдельное меню, а фильтр загрузочных опций, регулирующий порядок старта операционных систем, располагается на самом видном месте.
Даже после замены старого доброго BIOS новомодным интерфейсом UEFI старт операционной системы по-прежнему сопровождается звуковым сигналом. Таким себе последним писком низкоуровневого ПО. Что ж, традиция есть традиция.
Читайте также: