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 проверяются подписи драйверов/модулей ядра, таким образом, вредоносный код в режиме ядра выполнить будет нельзя. Но это справедливо только, если нет физического доступа к компьютеру, т.к., в большинстве случаев, при физическом доступе ключи можно заменить на свои.
Для 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, и, по моему мнению, делает это эффективно. Спасибо за внимание!
Можно ли обновить мой BIOS на UEFI? Не совсем. UEFI нельзя прошить вместо BIOS, поскольку он занимает гораздо больше памяти. Но существует такая штука, как DUET. Это загружаемая из BIOS посредством отдельного загрузочного раздела среда UEFI, которая может быть полезна, если вы собираетесь использовать диски объемом >2Тб на своем старом железе с BIOS. Подробнее можно ознакомиться здесь: http://www.rodsbooks.com/bios2uefi/
Здесь за гибкую настройку приоритета загрузки отвечает целый модуль CSM
Что такое GPT? GUID Partition Table, GPT — стандарт формата размещения таблиц разделов на жестком диске. Он является частью интерфейса EFI. EFI использует GPT там, где BIOS использует MBR.
Где в GPT хранятся аналоги загрузочных секторов? EFI использует для хранения загрузчиков папку EFI/boot, находящуюся в корне раздела FAT32. По умолчанию должен загружаться файл /EFI/boot/bootx64.efi Если загружаемый диск размечен в стиле MBR, то наличие файловой системы FAT32 на первом разделе (если их несколько) и файла с загрузчиком, лежащего по дефолтному пути, являются единственными условиями загрузки с этого носителя (CD/DVD тоже поддерживаются). В случае, если диск размечен в стиле GPT, раздел необязательно должен быть первым, но у него должен присутствовать флаг boot (проверить и выставить можно через gparted)
Возможно ли сконвертировать диск из MBR в GPT и обратно без потери данных? Да. Для этого потребуется загрузочный диск/флешка с Gparted http://gparted.sourceforge.net/download.php После загрузки с загрузочного носителя откроется окно gparted, в котором в верхнем правом углу будет отображен рабочий диск (обычно это /dev/sda). Необходимо запомнить имя диска, который вы хотите сконвертировать, открыть терминал, и набрать там sudo gdisk /dev/sda где вместо sda, при необходимости, нужно подставить имя вашего диска. Затем нужно ввести команду w и подтвердить запись таблицы GPT на диск. Все, диск преобразован в таблицу GPT. Для обратной конвертации в MBR необходимо таким же образом открыть gdisk для вашего диска, и последовательно набрать команду r, затем g, после чего подтвердить запись новой таблицы при помощи команды w. Так же в среде Windows вам поможет программа Partition Guru либо аналоги.
Процесс загрузки при использовании EFI отличается от процесса загрузки компьютера с BIOS
В случае использования EFI происходит следующее:
Описание от Redhat
/boot/efi/EFI/redhat/ содержит grub.efi — версию загрузчика, скомпилированную специально для EFI. В самом простом случае менеджер загрузки EFI выбирает этот файл в качестве загрузчика и загружает его в память.
Если раздел ESP содержит другие программы EFI, менеджер загрузки предложит выбрать программу для выполнения.
Как только GRUB определит операционную систему или ядро для загрузки, они будут загружены в память и им будет передано управление.
Так как производители оборудования обычно добавляют собственные каталоги в раздел ESP, необходимо создать условия для цепной загрузки. Менеджер загрузки EFI может запустить загрузчики любых операционных систем, если они расположены в ESP.
Booting an OS using UEFI
Multibooting on UEFI
Linux Windows x86_64 UEFI-GPT Multiboot
Boot Process under UEFI
Detecting UEFI Firmware Arch
Some of the known systems using these firmwares are Asus EZ Mode BIOS (in Sandy Bridge P67 and H67 motherboards), MSI ClickBIOS, HP EliteBooks, Sony Vaio Z series, many Intel Server and Desktop motherboards
To find out the arch of the efi firmware in a Mac, boot into Mac OS X and type the following command
UEFI Support in Linux Kernel
Linux Kernel config options for UEFI
The required Linux Kernel configuration options for UEFI systems are :
GUID Partition Table GPT config option — mandatory for UEFI support
UEFI Variables Support
Userspace Tools
There are few tools that can access/modify the UEFI variables, namely
Non-Mac UEFI systems
efibootmgr
To use efibootmgr, first load the ‘efivars’ kernel module:
To determine the actual device path for the UEFI System Partition (should be in the form /dev/sdXY ), try :
Then create the boot entry using efibootmgr as follows :
Linux Bootloaders for UEFI
Create an UEFI System Partition in Linux
For GPT partitioned disks
For MBR partitioned disks
UEFI Shell
UEFI Shell download links
Launching UEFI Shell
Important UEFI Shell Commands
To dump a list of current boot entries —
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu
To remove the 4th boot option
For bcfg help text
To edit, for example rEFInd’s refind.conf in the UEFI System Partition (fs0: in the firmware)
Спецификация UEFI (Unified Extensible Firmware Interface, Унифицированный расширяемый микропрограммный интерфейс, унифицированный расширяемый интерфейс прошивки или расширяемый аппаратный интерфейс), ранее известная как Extensible Firmware Interface ( EFI ), определяет интерфейс между операционной системой и микрокодом (микропрограммами), управляющим оборудованием. Другими словами, UEFI это интерфейс, который располагается “поверх” аппаратных компонентов компьютера, которые, в свою очередь, функционируют на собственных прошивках (микрокодах).
Давайте теперь совершим небольшой экскурс в историю персональных компьютеров, с целью понять причины, которые приводили к попыткам замены стандартного BIOS на что-то принципиально новое.
Старый-добрый BIOS
Основные принципы функционирования BIOS (базовой системы ввода-вывода) для персональных компьютеров были определены еще в конце 70х годов прошлого века. На протяжении довольно большого промежутка времени, прошедшего с той поры, компьютерная отрасль интенсивно развивалась, это приводило к тому, что на определенных этапах возможностей BIOS было недостаточно, поскольку выпускаемые производителями устройства имели на борту новые технологии, часто не совместимые с текущими версиями BIOS. Что бы уйти от подобных проблем, разработчикам приходилось порой довольно существенно модифицировать код BIOS, однако целый ряд ограничений так и остался неизменным до настоящего времени. И, если первоначально архитектура BIOS была достаточно простой, то по прошествии времени она неминуемо усложнялась, адаптируясь под все новые и новые технологии, поэтому, к определенному моменту она стала напоминать нагромождение различного рода устаревшего и плохо взаимодействующего между собой кода. Ограничения, которые и по сей день можно встретить в коде BIOS, объясняются необходимостью сохранять совместимость с базовыми функциями, необходимыми для функционирования старого ПО. Всё это привело к тому, что BIOS, по сути, стал самым устаревшим компонентом современных ПК. На данный момент BIOS мало удовлетворяет требованиям новейшего оборудования и имеет следующие недостатки:
Все эти, а так же некоторые другие, недостатки традиционной модели BIOS и привели к тому, что коалиция производителей аппаратуры и ПО начала работать над созданием спецификации UEFI. Начиная, по собственным наблюдениям, где-то с 2010 года, спецификация UEFI начала массово внедряться во все вновь выпускаемые материнские платы ведущих производителей, поэтому на данный момент найти новый компьютер с традиционным BIOS практически невозможно. Однако, сильно огорчаться из-за этого не стоит, поскольку многие производители в своих системных платах сохраняют совместимость с функционалом традиционных BIOS. К примеру, очень важным моментом является поддержка традиционного режима загрузки при помощи MBR. С этой целью был разработан UEFI-модуль режима эмуляции BIOS, который носит название Compatibility Support Module (CSM). Правда, я так полагаю, со временем все меньше и меньше производителей будут поддерживать в своих прошивках данный режим.
Преимущества UEFI
Тут я хотел бы определить достоинства интерфейса UEFI:
Недостатки UEFI
А теперь хотелось бы осветить недостатки технологии UEFI:
Алгоритм работы UEFI
В процессе создания UEFI, разработчиками с самого начала были установлены жесткие рамки для каждого процесса, участвующего в ходе выполнения. Первые три фазы (SEC, PEI, DXE) подготавливают платформу для загрузчика ОС, четвертая фаза (BDS) непосредственно производит загрузку загрузчика ОС. Давайте попробуем разобрать алгоритм работы UEFI и подробнее рассмотреть все его фазы.
Алгоритм работы UEFI Boot Manager
Концепция загрузки UEFI существенно отличается от аналогичной в BIOS. Если вспомнить BIOS, то за загрузку там отвечал код начального загрузчика int 19h (bootstrap loader), задача которого состояла лишь в том, чтобы загрузить главную загрузочную запись (MBR) с устройства загрузки в память и передать ей управление. В UEFI всё несколько интереснее, она содержит свой собственный полноценный встроенный загрузчик, который носит название UEFI Boot Manager (Менеджер загрузки UEFI или просто Boot Manager), имеющий куда более богатый функционал.
Boot Manager реализует довольно широкий набор функций, в число которых входит загрузка таких UEFI-образов, как: UEFI-загрузчиков ОС первой стадии, UEFI-драйверов, UEFI-приложений. Загрузка может производиться из любого UEFI-образа, размещенного на любой поддерживаемой UEFI файловой системе, располагающейся на любом поддерживаемом платформой физическом носителе информации. UEFI Boot Manager имеет свою собственную конфигурацию, параметры которой в виде ряда переменных располагаются в общей NVRAM (Non-volatile RAM).
Вот так, примерно, я представляю себе алгоритм перебора носителей в процессе работы UEFI:
Требования к загрузочным носителям UEFI
Спецификация UEFI, наряду с прочим, описывает и определенные требования к правилам размещения разделов и загрузчиков на носителях. И для различных классов устройств, как мы увидим далее, они существенно отличаются.
Ранее мы уже разбирали последовательность запуска сервера на примере устаревшего Legacy. Настало время познакомиться с 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 лежит в открытом доступе и состоит из нескольких документов:
UEFI универсален, но в данной статье мы будем опираться на стандарт, поглядывая в сторону процессоров на архитектуре x86_64.
Wake up, Neo!
В соответствии с принятой терминологией ядро/поток процессора здесь и далее будет называться процессором: начальным (bootstrap processor) или прикладным (application processor).
Как и в Legacy, процессор начинает выполнять первую инструкцию в конце адресного пространства по адресу 0xFFFFFFF0. Эта инструкция — прыжок на первую фазу инициализации платформы — SEC.
Фаза SEC (Security)
В данной фазе должны быть решены следующие задачи:
Следом происходит обработка события включения. Под этим подразумевается агрегация информации о состояниях оборудования, чтобы на следующей фазе некоторые модули могли сделать выводы о «здоровье» и общем состоянии платформы.
Во время фазы 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 и стать корнем доверия, во время выполнения этой фазы код, которому мы планируем передать управление, может быть проверен на отсутствие несанкционированных изменений и вредоносных частей программы.
В конце выполнения SEC собрана следующая информация:
Фаза PEI (Pre EFI Initialization)
Фаза PEI на материнской плате SuperMicro Задача фазы Pre EFI Initialization заключается в сборе информации о подключенных устройствах и подготовке минимально необходимого количества оборудования для запуска процесса полной инициализации.
По своей задумке фаза PEI должна быть легковесной, так как память процессорного кэша ограничена. Помимо этого, в фазе PEI может происходить восстановление после сбоя, поэтому есть потребность размещать код фазы PEI в более отказоустойчивом хранилище.
Данная фаза состоит из ядра, называемого PEI Foundation, и подключаемых модулей PEI Module (PEIM). Центральной частью ядра является диспетчер модулей, PEI Dispatcher, который управляет порядком исполнения модулей, а также организует межмодульное взаимодействие (PEIM-to-PEIM Interface, PPI).
Отметим, что фаза SEC исполнялась с флэш-памяти на материнской плате, и только в начале PEI необходимый для этой фазы исполняемый код копируется во временную оперативную память.
Далее к работе приступает PEI Dispatcher. Он запускает PEI модули в конкретном порядке: сначала модули без зависимостей, затем зависящие от первых и так до тех пор, пока модули не закончатся.
Архитектура фазы PEI позволяет разрабатывать собственные модули, которые могут передавать результаты своей деятельности в следующую фазу. Передача информации происходит через специальную структуру данных Hand-off Block (HOB).
В процессе запуска PEI модулей отметим следующие:
Состояние S3 (Suspend to RAM) — это состояние сна, при котором процессор и часть чипсета отключаются с потерей контекста. При пробуждении из такого состояния процессор начинает выполнение как при обычном включении. Но вместо полной инициализации и прохождения всех тестов система ограничивается восстановлением состояния всех устройств.
При запуске из любого другого состояния управление передается в фазу Driver Execution Environment.
Фаза DXE (Driver eXecution Environment)
Инициализация механизма AHCI в фазе DXE Задача фазы Driver Execution Environment (DXE) сводится к инициализации оставшихся устройств. К моменту старта фазы DXE процессор и основная память уже готовы к работе, а на драйверы DXE не накладываются строгие ограничения по потребляемым ресурсам.
Аналогично PEI Foundation в данной фазе есть собственное ядро — DXE Foundation. Ядро создает необходимые интерфейсы и загружает три вида DXE сервисов:
В UEFI нет специализированной фазы, где оборудование проходит POST (Power-On Self-Test). Вместо этого каждый модуль PEI и DXE фазы проводит свой набор тестов и сообщает об этом с помощью POST-кодов пользователю и с помощью HOB в следующие фазы.
Дополнительно отметим модуль Compatibility Support Module (CSM), который обеспечивает совместимость с Legacy и позволяет загружать ОС без поддержки UEFI. Позднее мы рассмотрим этот модуль подробнее.
После инициализации всего оборудования наступает время выбора загрузочного устройства.
Фаза BDS (Boot Device Select)
В фазе Boot Device Select реализуется политика загрузки приложений UEFI. Несмотря на то, что это отдельная фаза, все сервисы, включая диспетчера, созданные на фазе DXE, остаются доступны.
Цель фазы BDS сводится к выполнению следующих задач:
PCIe BIOS карты расширения LSI Поиском загружаемых областей на устройствах занимается Boot Manager. На некоторых картах расширения, например, на сетевых картах и RAID-контроллерах, может находиться собственный «BIOS», называемый Option ROM, или OpROM. Содержимое OpROM устройств запускаются сразу после обнаружения, а после выполнения управление возвращается в Boot Manager.
Все разделы, на которых находятся загружаемые области, сохраняются в памяти менеджера загрузки и упорядочиваются в соответствии с порядком загрузки. Если ни одного приложения не нашлось, Boot Manager может вызвать диспетчера DXE, на случай если за время поисков диспетчер загрузил дополнительные драйвера и менеджеру загрузки могут «открыться» новые устройства.
Как отмечалось ранее, использование разметки Master Boot Record накладывает ограничения на размер разделов и их количество на накопителе, а также вызывает определенные неудобства в содержании нескольких операционных систем. Решение всех этих проблем является частью спецификации UEFI — GUID Partition Table.
GPT (GUID Partition Table)
GUID Partition Table — это стандартизированный формат размещения таблиц разделов, пришедший на смену устаревшей MBR.
Во-первых, GPT использует адресацию логических блоков (Logical Block Addressing, LBA) вместо адресации «Цилиндр — Головка — Сектор» («Cylinder, Head, Sector», CHS). Смена способа адресации позволяет GPT работать с накопителями объемом до 9.4 ЗБ (9.4 * 10 21 байт) против 2.2 ТБ у MBR.
Во-вторых, таблица разделов претерпела изменения, и теперь в пределах одного накопителя можно создать до 2 64 разделов, хотя операционные системы поддерживают не более 128 в случае Microsoft Windows и 256 в случае Linux.
В-третьих, каждый раздел имеет свой идентификатор типа, который описывает назначение раздела. Так, например, идентификатор C12A7328-F81F-11D2-BA4B-00A0C93EC93B однозначно указывает на системный раздел EFI (EFI System Partition, ESP), с которого Boot Manager может попробовать загрузить приложение.
При разработке GPT не обошли стороной и совместимость с MBR. Дисковые утилиты могли не распознать GPT диск и затереть его. Чтобы избежать этого, при разметке GPT первые 512 байт заполняются защитной MBR (Protective MBR) — разметкой из одного раздела на весь накопитель с системным идентификатором 0xEE. Такой подход позволяет UEFI понимать, что перед ним не настоящий MBR, а старому программному обеспечению без поддержки GPT — видеть раздел с данными неизвестного типа.
В GPT отказались от загрузочной области в пользу ESP-разделов, которые распознаются как загрузочные. Boot Manager собирает информацию обо всех ESP на диске, что позволяет без конфликтов иметь несколько загрузчиков на накопителе, по одному на каждый ESP.
Загрузка операционной системы
После опроса всех устройств и поиска загрузочных областей Boot Manager начинает загружать в порядке приоритета загрузки. В общем случае управление передается в UEFI-приложение, которое начинает выполнять свою логику. Однако для систем с совместимостью с Legacy режимом в списке загрузочных областей может найтись накопитель с разметкой MBR и придется обращаться к CSM, модулю поддержки совместимости.
Модуль CSM позволяет запускать операционные системы, которые не поддерживают UEFI. Для загрузки таких ОС модуль CSM эмулирует окружение, в которое попадает «классическая» ОС:
Фаза RT (Run Time)
Начало загрузки ОС или Legacy-загрузчика приводит к началу фазы Run Time. В данной фазе все сервисы DXE (кроме UEFI Runtime Services) перестают быть доступны.
Содержимое фазы RT может быть разным. Здесь может быть привычный по Legacy загрузчик ОС — например, GRUB2 или Windows Boot Manager, который переводит процессор в 64-битный режим и запускает ОС. Но могут быть и самостоятельные приложения или сразу ядро операционной системы.
Ядро Linux начиная с версии 3.3 при наличии флага CONFIG_EFI_STUB превращается в обычное UEFI-приложение и может быть запущено из UEFI без использования сторонних загрузчиков.
Как и в случае с Legacy, загрузчику или самому ядру необходимо перевести процессор в 64-битный режим, загрузить все драйвера, настроить планировщик и запустить init. Init, в свою очередь, запускает процессы в пространстве пользователя, после чего появляется окно логина в ОС.
Заключение
Загрузка в UEFI — это более сложный, но стандартизированный и во многом универсальный процесс. Схожесть с Legacy наблюдается лишь в общих чертах, а дьявол, как известно, кроется в деталях.
Как Вы думаете, как скоро получится полностью уйти от Legacy? Пишите свое мнение в комментариях.
