Open runtime efi что это

Обновлено: 06.07.2024

Файлы EFI являются загрузчиками UEFI и вот как они работают

Файл с расширением EFI является файлом интерфейса расширяемого микропрограммного обеспечения.

Файлы EFI являются исполняемыми файлами загрузчика, существуют в компьютерных системах на основе UEFI (Unified Extensible Firmware Interface) и содержат данные о том, как должен происходить процесс загрузки.

Файлы EFI можно открывать с помощью EFI Developer Kit и Microsoft EFI Utilities, но, честно говоря, если вы не разработчик оборудования, мало смысла в «открытии» файла EFI.

Где находится файл EFI в Windows?

В системе с установленной операционной системой диспетчер загрузки, существующий как часть прошивки UEFI материнской платы, будет иметь расположение файла EFI, хранящееся в переменной BootOrder . Это может быть еще один менеджер загрузки, если у вас установлен мультизагрузочный инструмент, но обычно это просто загрузчик EFI для вашей операционной системы.

В большинстве случаев этот файл EFI хранится в специальном системном разделе EFI. Этот раздел обычно скрыт и не имеет буквы диска.

Например, в системе UEFI с установленной Windows 10 файл EFI будет расположен в следующем месте в этом скрытом разделе:

Вы увидите файл bootx64.efi , если у вас установлена 64-разрядная версия Windows, или файл bootia32.efi , если вы используете 32-разрядную версию. , Смотрите 64-битные и 32-битные: в чем разница? подробнее об этом, если вы не уверены.

На некоторых компьютерах Windows файл winload.efi действует как загрузчик и обычно хранится в следующем месте:

Если системный диск отличается от C или Windows установлена в папку, отличную от Windows , то точный путь на вашем компьютере, конечно, будет отличаться соответственно.

В системе без установленной операционной системы с пустой переменной BootOrder менеджер загрузки материнской платы ищет в предопределенных местах файл EFI, например на дисках в оптических дисках и другие связанные СМИ. Это происходит потому, что, если это поле пустое, у вас не установлена работающая ОС, и, вероятно, вы собираетесь установить одну из следующих.

Например, на установочном DVD-диске Windows 10 или образе ISO существуют следующие два файла, которые менеджер загрузки UEFI вашего компьютера быстро найдет:

Где находится файл EFI в других операционных системах?

Вот некоторые местоположения файлов EFI по умолчанию для некоторых операционных систем, отличных от Windows:

macOS использует следующий EFI-файл в качестве загрузчика, но не во всех ситуациях:

Загрузчик EFI для Linux будет отличаться в зависимости от установленного дистрибутива, но вот несколько:

Все еще не можете открыть или использовать файл?

Обратите внимание, что есть некоторые типы файлов, которые очень похожи на «.EFI», которые у вас могут быть, и поэтому вы можете открыть их с помощью обычной программы. Это наиболее вероятно, если вы просто неправильно прочитали расширение файла.

Например, у вас действительно может быть файл факсимильного документа eFax EFX, который не имеет ничего общего с файлами расширяемого интерфейса микропрограммы и является документом, который открывается службой факса. Или, может быть, ваш файл использует расширение .EFL и является файлом с внешним форматом или зашифрованным файлом Encryptafile.

Если вы уверены, что можете открыть файл, который у вас есть, то он, скорее всего, не в том формате, который описан на этой странице. Вместо этого дважды проверьте расширение файла для вашего файла и исследуйте программу, которая может открыть его или преобразовать в новый формат.

Вы можете даже попробовать загрузить его в службу конвертации файлов, например Zamzar, чтобы узнать, распознает ли он тип файла и предложить формат преобразования.

EFI (Extensible Firmware Interface) — интерфейс по централизации оборудования в момент включения системы. Регулирует процессы, происходящие между операционной системой и микропрограммами, осуществляющими управление низкоуровневыми функциями оборудования. EFI загружает компьютер, а впоследствии передает управление загрузчику операционной системы. Является логической заменой интерфейса BIOS, традиционно исользующегося IBM PC-совместимыми компьютерами.

Компания Intel разработала первую спецификацию EFI. Позднее, интерфейс поменял название: последняя версия стандарта именуется UEFI (Unified Extensible Firmware Interface). На сегодняшний день, стандарт UEFI разрабатывается ассоциацией Unified EFI Forum.

Стандарт EFI имеет поддержку графического меню, а также некоторых дополнительных возможностей (к примеру, Aptio или Great Wall UEFI).

История

Первоначально, стандарт EFI предназначался для использования в первых системах Intel-HP Itanium, появившихся в середине 90-х годов. Те ограниченные возможности, которые демонстрировал PC-BIOS (16-битный код, адресуемая память 1 Мбайт, ограничения аппаратного характера IBM PC/AT и прочее) были неприемлемы для использования в больших серверных платформах, а ведь Itanium планировался именно для таковых.

Примечательно, что EFI изначально носил название Intel Boot Initiative, это уже позже он был переименован.

Спецификации

История стандарта EFI началась с выхода версии 1.01, но она не увидела широкого применения, посколько была быстро снята с рынка в связи с юридическими проблемами, связанными с использованием торговой марки.

Первая «полноценная» версия EFI - это 1.02, которая была представлена 12 декабря 2000 года.

Поздее, 1 декабря 2002 года была представлена версия EFI 1.10, включавшая в себя модель драйвера EFI, а также несколько «косметических» улучшений, в сравнении с версией 1.02.

В 2005 году компания Intel отнесла спецификацию EFI к организации UEFI Forum, которая впоследствии стала отвечать за дальнейшее развитие интерфейса. Тогда же стандарт EFI был переименован в Unified EFI (UEFI), для того, чтобы подчеркнуть произошедшее изменение. Примечательно, что, несмотря на смену названия, в большинстве документов по сей день свободно применяются оба термина.

7 января 2007 года организация UEFI Forum выпустила версию 2.1 UEFI, в которой была внедрена улучшенная криптография, функция установления подлинности сети, а также обновленная архитектура пользовательского интерфейса.

Содержание

Интерфейс EFI содержит в себе таблицы, в которых включено множество различных данных: информация о платформе, загрузочные и runtime-сервисы, доступные для загрузчика операционной системы и самой операционной системы. Некоторые расширения BIOS (ACPI или SMBIOS) также включены в EFI - в них не обязателен 16-разрядный runtime-интерфейс.

Сервисы

EFI определяет сервисы загрузки, включающие поддержку:

текстовой и графической консоли;
шин;
блоков;
файловых сервисов;

также интерфейс определяет runtime-сервисы (дата, время и память).

Драйверы устройств

Стандарт EFI, помимо стандартных, архитектурно-зависимых драйверов, определяет также и независимую от платформы среду драйверов. эта среда носит название EFI Byte Code (EBC). Спецификация UEFI требует от системного программного обеспечения интерпретатор для любых образов EBC, загруженных (фактически или потенциально) в среду.

Так, EBC вполне можно соотнести с независимым от аппаратных средств Open Firmware, используемым в Apple Macintosh и Sun Microsystems SPARC компьютерах.

Часть архитектурно-зависимых типов драйверов EFI может оснащаться интерфейсами для использования операционной системы, что дает возможность самой операционной системе применять EFI в качестве базовой поддержки графики и сети до загрузки драйверов.

Менеджер загрузки

Менеджер загрузки EFI применяется в целях выбора и последующей загрузки операционной системы. Так, потребность в определенном алгоритме загрузки исключена: загрузчик является приложением EFI.

Поддержка дисков

Вдобавок к стандартному методу разметки дисков (MBR), EFI обладает поддержкой GUID Partition Table (GPT). Эта схема свободна от каких-либо специфических для MBR ограничений. Стандарт EFI не содержит в себе описание для файловых систем, но реализации EFI, как правило, имеют поддержку файловой системы FAT32.

Оболочка

Открытая среда оболочки стандарта позволяет пользователю загружать ее в целях произведения определенных операций. Это гораздо удобнее: пользователь избавлен от загрузки непосредственно самой операционной системы. Оболочка является простым приложением EFI, которое может храниться в ПЗУ платформы (либо на отдельном устройстве, драйверы которого расположены в ПЗУ).

Кроме того, пользователь может применять оболочку и для выполнения иных приложений EFI (например, настройка или установка операционной системы, либо же диагностика, конфигурация или обновление прошивки). Также в функции оболочки входит проигрывание CD/DVD-носителей, без загрузки операционной системы. Кроме того, оболочка EFI позволяет командно произвести операции копирования или перемещения файлов и каталогов, при условии, что работа производится в поддерживаемых файловых системах. Можно также осуществлять загрузку/выгрузку драйверов. Ну, и наконец, оболочка может использовать полный TCP/IP стек.

Оболочка EFI имеет поддержку сценариев в виде файлов с расширением .nsh (аналог пакетного файла в DOS).

Расширения

Расширения EFI загружаются почти с любого энергонезависимого устройства хранения данных, которое подключено к ПК.

Реализация

Intel Platform Innovation Framework

Intel Platform Innovation Framework («инновационный инструментарий Intel») представляет собой набор спецификаций, выпущенных компанией Intel при сотрудничестве с EFI. В данном случае, EFI определяет интерфейс между операционной системой и аппаратно-программным обеспечением, а на инструментарий возлагается определение применяемой для создания встраиваемого программного обеспечения структуры. Это определение производится на более низком уровне, в сравнении с функциями, заложенными в EFI.

К примеру, в инструментарий входят все этапы, которые необходимо преодолеть для корректной инициализации компьютера с момента включения. Такие внутренние возможности интегрированного программного обеспечения не являются частью спецификации EFI, однако они включены в разработанную ассоциацией UEFI спецификацию инициализации платформы (Platform Initialization Specification). Данный инструментарий опробован на платформах XScale, Itanium и IA-32.

Совместимость с операционной системой, в случае с платформой x86, достигается благодаря применению модуля поддержки совместимости (CSM), содержащего в себе 16-битную программу (CSM16), которая реализуется производителем BIOS. Также в нее входит специальный слой, в функции которого входит связь CSM16 с инструментарием.

Компания Intel является автором уникальной реализации для инструментария, имеющей кодовое название «Tiano». Это полная реализация встраиваемого программного обеспечения с поддержкой EFI. В ней отсутствует традиционная 16-битная часть CSM, однако она обеспечивает интерфейсы, которые необходимы для дополнений, реализуемых изготовителями BIOS. Компания Intel не распространяет полную реализацию Tiano среди конечных пользователей. Часть этой реализации была выпущена в виде исходных текстов TianoCore проекта, подобно EFI Developer Kit (EDK). Данная реализация включает EFI и часть кода инициализации аппаратных средств, но вместе с тем, в ней скрыты характерные особенности самого встраиваемого программного обеспечения.

Построенные на стандарте EFI продукты можно приобрести через независимых производителей BIOS (к примеру, American Megatrends (AMI) и Insyde Software). Часть реализаций полностью основана на Tiano, другая часть - соответствует спецификациям, однако не строится на реализации Intel.

Платформы, применяющие EFI; сопутствующий инструментарий

В 2000 году, компания Intel разработала системы, построенные на платформе Itanium. Они имели поддержку EFI 1.02.

В 2002 году, компания Hewlett-Packard выпустила системы, построенные на платформе Itanium 2. Они имели поддержку версии EFI 1.10, и имели возможность загружать операционные системы Windows, Linux, FreeBSD и HP-UX.

Системы Itanium или Itanium 2, выпускаемые вместе с интегрированным EFI-совместимым программным обеспечением, обязаны соответствовать спецификации DIG64.

В ноябре 2003 года, компания Gateway обнародовала систему Gateway 610 Media Center, которая являлась первой x86-системой, построенной на базе Windows. В ней использовалось встраиваемое программное обеспечение, которое было основано на инструментарии, InsydeH2O от Insyde Software. Поддержка BIOS реализовывалась благодаря модулю поддержки совместимости (CSM).

Январь 2006 года, компания Apple представляет свои первые ПК Macintosh, построенные на платформе Intel. Системы применяют EFI и сопутствующий инструментарий, взамен Open Firmware, который применяли на предыдущих системах PowerPC-платформы.

5 апреля 2006 года, компания Apple представляет продукт Boot Camp, являющийся стандартным пакетом, позволяющим создавать диск с драйверами Windows XP. Кроме того, новый пакет содержал в себе инструмент разметки дисков, позволяющий установить Windows XP, оставив при этом работоспособным действующий Mac OS X. Кроме того, вышло обновление встраиваемого программного обеспечения. В нем была добавлена поддержка BIOS для реализации EFI. Последующие линейки моделей компьютеров Macintosh выпускались с обновленным и встраиваемым программным обеспечением. Так, на сегдняшний день, все компьютеры Macintosh имеют возможность загружать BIOS-совместимые операционные системы.

Фирменные «интеловские» системные платы производятся, в основном, со встраиваемым программным обеспечением, построенным на основе инструментария (к примеру, DP35DP). Так, в 2005 году было выпущено свыше 1 млн. систем Intel. Производство новых сотовых телефонов, настольных ПК и серверов, работающих на инструментарии, стартовало в 2006 году. Вот, например, все системные платы, построенные на наборе системной логики Intel 945, применяют в своей работе инструментарий. Впрочем, во встраиваемом программном обеспечении, как правило, не включена поддержка EFI, оно ограничивается лишь поддержкой BIOS.

С 2005 года стандарт EFI стали внедрять в не-ПК архитектуры (например, встраиваемые системы, построенные на базе XScale). В EDK включена отдельная цель NT32, допускающая встраиваемое программное оебспечение EFI и его приложения в приложения Windows. В 2007 году компанией Hewlett-Packard был представлен принтер серии 8000. Это был первый принтер, оснащенный встраиваемым программным обеспечением, совместимым с EFI. В 2008 году компанией MSI была представлена линейка системных плат, построенных на чипсете Intel P45, они обладали поддержкой EFI.

Операционные системы

С 2000-х годов, операционные системы GNU/Linux нередко применяли EFI для загрузки.
С 2002 года, операционные системы HP-UX стали применять EFI в качестве загрузочного механизма в системах, построенных на платформе IA-64. Операционные системы OpenVMS применяли стандарт с начала 2005 года.
Компания Apple взяла на вооружение стандарт EFI, выпустив линейку компьютеров, построенных на архитектуре Intel. Mac OS X 10.4 (Tiger) для Intel и Mac OS X 10.5 (Leopard) имели поддержку EFI v1.10 не только в 32-разрядном режиме, но и в 64-разрядных центральных процессорах. Так, посредством загрузчика EFI, установка Microsoft Windows 7 на компьютеры Apple осталась невозможной, поскольку этой операционной системе необходимо наличие UEFI или еще более новой версии.
Microsoft Windows имеет поддержку EFI для 64-разрядных архитектур. Компания Microsoft отмечает, что отсутствие поддержки EFI на 32-разрядных центральных процессорах возникла ввиду недостаточного участия со стороны производителей ПК. Миграция Microsoft к 64-разрядным операционным системам не позволяет использовать EFI 1.10, поскольку 64-разрядные расширения не поддерживаются окружением процессора. Поддержка x86-64 включена в UEFI 2.0. Itanium версии Windows 2000 (Advanced Server Limited Edition и Datacenter Server Limited Edition) имеют поддержку EFI 1.1.Windows Server 2003 для IA-64, 64-разрядная версия Windows XP и Windows 2000 Advanced Server Limited Edition, заточенные специально под семейство процессоров Intel Itanium, имеют поддержку EFI, определенную для данной платформы спецификацией DIG64. Разработчики компании Microsoft внедрили поддержку UEFI в 64-разрядных операционных системах Windows начиная с Windows Server 2008 и Windows Vista Service Pack 1.

Недостатки

Стандарт EFI попал под оглушительные шквалы критики за усложнение системы. Многие эксперты отмечали, что EFI не дает операционной системе ключевых преимуществ, но при этом существенно ее усложняет. Кроме того, в пользу EFI произошел отказ от альтернативных реализаций BIOS, обладающих полностью открытыми исходными текстами (OpenBIOS и coreboot).

Содержание

История

Спецификация EFI 1.02 была выпущена Intel 12 декабря 2000 года. (Версия 1.01 имела проблемы в юридическом плане, связанные с торговой маркой, и была быстро изъята).

Спецификация EFI 1.10 была выпущена 1 декабря 2002 года. Она включала модель драйвера EFI, а также несколько незначительных улучшений по сравнению с версией 1.02.

В 2005 году Intel внесла эту спецификацию в UEFI Forum, который теперь ответственен за развитие и продвижение EFI. [2] EFI был переименован в Unified EFI (UEFI), чтобы отразить это изменение, при этом большая часть документации использует оба термина.

UEFI Forum выпустил спецификацию 2.1 UEFI 7 января 2007 года. Она добавила и улучшила криптографию, установление подлинности сети и архитектуру пользовательского интерфейса.

Текущая спецификация UEFI версии 2.3.1 была представлена в апреле 2011 года.

Содержание

Интерфейс, определённый спецификацией EFI, включает таблицы данных, содержащие информацию о платформе, загрузочные и runtime-сервисы, которые доступны для загрузчика операционной системы (ОС) и самой ОС. Некоторые существующие расширения BIOS, типа ACPI и SMBIOS, также присутствуют в EFI, поскольку не требуют 16-разрядного runtime-интерфейса.

Сервисы

EFI определяет «загрузочные сервисы», которые включают поддержку текстовой и графической консоли на различных устройствах, шин, блоков и файловых сервисов, и runtime-сервисы, например дата, время и энергонезависимая память.

Драйверы устройств

В дополнение к стандартным, архитектурно-зависимым драйверам устройств, спецификация EFI предусматривает независимую от платформы среду драйверов, названную EFI Byte Code (EBC). От системного встраиваемого ПО (firmware) спецификацией UEFI требуется иметь интерпретатор для любых образов EBC, которые загружены или могут быть загружены в среду. В этом смысле EBC подобен Open Firmware, независимому от аппаратных средств встраиваемому ПО, используемому в компьютерах Apple Macintosh и Sun Microsystems SPARC.

Некоторые архитектурно-зависимые (non-EBC) типы драйверов EFI могут иметь интерфейсы для использования ОС. Это позволяет ОС использовать EFI для базовой поддержки графики и сети до загрузки драйверов, определённых в ОС.

Менеджер загрузки

Менеджер загрузки EFI используется для выбора и загрузки ОС, исключая потребность в специализированном механизме загрузки (загрузчик ОС является приложением EFI).

Поддержка дисков

Оболочка EFI

Оболочка может использоваться для выполнения других приложений EFI, таких как настройка, установка ОС, диагностика, утилиты конфигурации и обновления прошивок. Она также может использоваться, чтобы проиграть CD или DVD-носители не загружая ОС, при условии, что приложения EFI поддерживают эти возможности. Команды оболочки EFI также позволяют копировать или перемещать файлы и каталоги в поддерживаемых файловых системах, загружать и выгружать драйверы. Также оболочкой может использоваться полный TCP/IP-стек.

Оболочка EFI поддерживает сценарии в виде файлов .nsh, аналогичных пакетным файлам в DOS.

Расширения

Расширения EFI могут быть загружены с практически любого энергонезависимого устройства хранения данных, присоединённого к компьютеру. Например, OEM-производитель может продать систему с разделом EFI на жёстком диске, который добавил бы дополнительные функции к встраиваемому ПО EFI, размещённому в ПЗУ системной платы.

Реализация

Intel Platform Innovation Framework для EFI

В частности, инструментарий включает все шаги, необходимые для инициализации компьютера после включения. Эти внутренние возможности встраиваемого ПО не определены как часть спецификации EFI, но включены в спецификацию инициализации платформы (Platform Initialization Specification), разработанную UEFI. Инструментарий был проверен на платформах XScale, Itanium и IA-32.

Часть Tiano была выпущена в виде исходных текстов TianoCore проекта как EFI Developer Kit (EDK). [5] Эта реализация включает EFI и некоторый код инициализации аппаратных средств, но не раскрывает полностью особенностей непосредственно встраиваемого ПО. Несколько лицензий использовались для этого кода, включая BSD license и Eclipse Public License.

Продукты, основанные на EFI, UEFI и спецификациях инструментария, доступны через независимых производителей BIOS, например, American Megatrends (AMI) и Insyde Software. Некоторые реализации производителей полностью основаны на Tiano, в то время как другие, соответствуют спецификациям, но не основываются на эталонной реализации Intel. [6]

Платформы, использующие EFI или инструментарий

Выпущенные в 2000 году Intel системы на платформе Itanium поддерживали EFI 1.02.

Выпущенные в 2002 году Hewlett-Packard системы на платформе Itanium 2 поддерживали EFI 1.10; они могли загружать Windows, Linux, FreeBSD и HP-UX.

Все системы Itanium или Itanium 2, которые выпускаются с EFI-совместимым встраиваемым ПО, должны соответствовать спецификации DIG64.

В январе 2006 года Apple представила первые компьютеры Macintosh на платформе Intel. Эти системы используют EFI и инструментарий вместо Open Firmware, который использовался на предыдущих системах платформы PowerPC. [7]

5 апреля 2006 года Apple выпустила пакет Boot Camp, который позволяет создать диск с драйверами Windows XP, а также содержит неразрушающий инструмент разметки дисков, позволяющий установить Windows XP совместно с Mac OS X. Также было выпущено обновление встраиваемого ПО, которое добавило поддержку BIOS для данной реализации EFI. Последующие модели Macintosh были выпущены с обновлённым встраиваемым ПО. Теперь все современные компьютеры Macintosh могут загружать BIOS-совместимые ОС, такие как Windows XP, Vista и Windows 7.

Большое количество системных плат фирмы Intel выпускается с встраиваемым ПО на основе инструментария (например, DP35DP). Так, в течение 2005 было выпущено более одного миллиона систем Intel. [8] Новые мобильные телефоны, настольные компьютеры и серверы, использующие инструментарий, начали производить в 2006 году. Например, все системные платы, которые построены на наборе системной логики Intel 945, используют инструментарий. Однако производимое встраиваемое ПО обычно не включает поддержку EFI и ограничено поддержкой BIOS. [9]

С 2005 года EFI начал применяться в не-ПК архитектурах, таких, как встраиваемые системы на ядре XScale. [10]

EDK включает цель NT32, которая позволяет встраиваемому ПО EFI и приложениям EFI выполняться в приложениях Windows.

В 2007 году компания Hewlett-Packard выпустила многофункциональный принтер серии 8000, оснащённый встраиваемым ПО, совместимым с EFI. [11]

В 2008 году компания MSI выпустила линейку системных плат на чипсете Intel P45 с поддержкой EFI, [12]

Операционные системы

Графические возможности

EFI поддерживает графические меню и некоторые возможности, например, осуществленные Aptio или Great Wall UEFI. [21]

Критика

В сентябре 2011 года Matthew Garrett предупредил о том, что условия сертификации компьютеров как совместимых с Microsoft Windows 8, могут привести к появлению компьютеров, на которые невозможно будет установить какую‐либо другую операционную систему. [24] [25] Microsoft заявила, что поставщики могут реализовать возможность добавления других подписей, и позже сделала это обязательным требованием сертификации, однако для устройств на ARM (ранее речь могла идти о мобильных устройствах с ОС Windows Phone, но как раз в те дни Qualcomm объявила о планах выпуска субноутбуков с поддержкой Windows 8) требование противоположное: отключение «безопасной загрузки» (и, соответственно, установка других ОС) должно быть невозможным. [26]

Отличия в процессе загрузки BIOS и UEFI

При разработке UEFI участники форума с самого начала установили четкие рамки для каждого процесса. Процедуру загрузки (PI, Platform Initialization — инициализация платформы)материнской платы, основанной на UEFI, также можно разделить на несколько этапов. Первым из них, следующим непосредственно за включением компьютера,является Pre-EFI Initialization (PEI): система загружает модули инициализации процессора, памяти и чипсета и выполняет их. Затем осуществляется переход в окружение исполнения драйверов (DXE). В этот момент производится активация остальных компонентов, причем одновременно нескольких.

В UEFI можно интегрировать большое количество драйверов, не привязанных к определенной системе. Это значит, что производителям достаточно написать всего одну версию драйвера для всех платформ. Благодаря инициализации драйверов на этом раннем этапе запуска можно получить доступ к сетевой плате, в том числе функциям загрузки по сети или удаленного обслуживания. Кроме того, при активной графической подсистеме можно наслаждаться привлекательно оформленным меню UEFI.

Наибольший выигрыш во времени запуска достигается благодаря тому, что отпадает необходимость в поиске загрузчика на всех устройствах: загрузочный диск назначается в UEFI на этапе установки ОС. Ускорение старта системы не единственное достоинство UEFI. В отдельном EFI-разделе можно хранить множество приложений. Так, еще до загрузки самой ОС можно запустить программу диагностики, антивирусное ПО или утилиту управления системой.

Давно назревший переход на платформу UEFI постоянно откладывался. Теперь это в прошлом, и во многом — благодаря жестким дискам емкостью 3 Тбайт, которые уже доступны в продаже. BIOS ПК, используя классическую MBR винчестера, способна получать доступ только к 2 32 секторам размером 512 байт, то есть максимум к 2 Тбайт (2,2 ТБ) дискового пространства. Seagate использует секторы большего размера с целью сделать всю емкость доступной хотя бы после старта Windows. При этом компьютер на основе BIOS не сможет загрузиться с такого диска. UEFI же работает с таблицей разделов GUID (GPT, GUID Partition Table), в которой размер адреса составляет 64 бита, и поддерживает до 2 64 секторов, то есть способен обращаться к девяти зеттабайтам (9 млрд. терабайт).

Еще одна особенность UEFI - Безопасный протокол загрузки. Он позволяет установить один или несколько подписанных ключей в прошивку системы. После включения, “безопасной загрузки” UEFI предотвращает загрузку исполняемых файлов или драйверов, если они не подписаны одним из заранее установленных ключей. Другой набор ключей (Pkek) позволяет поддерживать связь между ОС и прошивкой. ОС вместе с набором ключей соответствия Pkek, которые организует связь с установлеными в прошивку ключами, может добавлять дополнительные ключи в так называемый “белый список” в прошивке. Естественно, помимо этого она может добавить ключи в “черный список”. Бинарники, которые отметились в черном списке ключей, естественно не будут срабатывать при загрузке.

Windows 8 совместно с UEFI 2.3.1 закрывают дыру в безопасности текущей схемы BIOS, которая позволяет любому загрузчику, в том числе содержащему руткит, загружаться раньше операционной системы. В отличие от BIOS, UEFI будет позволять загружаться только подтверждённым загрузчикам ОС в случае, если разрешена безопасная загрузка. Это означает, что вредоносное ПО в загрузчиках находиться больше не сможет. Microsoft утверждала, что возможность отключить безопасную загрузку UEFI у пользователей все же будет, если поставщики материнских плат реализуют эту функцию. Это позволит устанавливать на персональные компьютеры GNU/Linux и любые другие операционные системы, включая старые Windows. Но здесь уже начинает страдать защита и к тому же Windows 8 работать уже не будет. Позже эта возможность была запрещена для мобильных устройств.

Всем привет. В рамках проекта от компании Acronis со студентами Университета Иннополис (подробнее о проекте мы уже описали это тут и тут) мы изучали последовательность загрузки операционной системы Windows. Появилась идея исполнять логику даже до загрузки самой ОС. Следовательно, мы попробовали написать что-нибудь для общего развития, для плавного погружения в UEFI. В этой статье мы пройдем по теории и попрактикуемся с чтением и записью на диск в pre-OS среде.

В компании Acronis команд, которые занимаются UEFI, не так много, поэтому я решил разобраться в вопросе самостоятельно. К тому же есть проверенный способ получить огромное количество точных советов совершенно бесплатно и свободно — просто начать делать что-либо и выложить это в интернет. Поэтому комментарии и рекомендации под этим постом очень приветствуются! Вторая цель данного поста собрать небольшой дайджест статей о UEFI и помочь двигаться в этом направлении.

Полезные ссылки

Для начала хочу перечислить список источников, которые мне очень помогли. Возможно вам они тоже помогут и ответят на ваши вопросы.

В первую очередь это UEFI and EDK II Learning and Development от tianocore. Прекрасно структурированный и иллюстрированный курс, который поможет понять что же происходит в момент загрузки и что такое UEFI. Если вы ищите точную теоретическую информацию по теме, вам туда. Если хочется поскорее перейти к написанию UEFI драйверов, то сразу в Lesson 3.
Статьи на хабре раз, два и три. Автору низкий поклон. Это отличное практическое руководство без лишних сложностей для начинающих. Частично в данной статье я буду цитировать эти шедевры, хоть и с небольшими изменениями. Без этих публикаций, было бы значительно тяжелее начать.
Для продолжающих рекомендую эту статью и другие этого же автора.
Так как мы планируем писать драйвер, очень поможет официальный гайдлайн по написанию драйвера. Наиболее правильные советы будут именно там.
Ну и на крайний случай спецификация UEFI.

Немного теории

Хочу напомнить требования и цели проекта Active Restore. Мы планируем приоритизировать файлы в системе для более эффективного восстановления. Для этого нужно запуститься на максимально раннем этапе загрузки ОС. Для понимания наших возможностей в мире UEFI стоит немного углубиться в теорию о том как проходит цикл загрузки. Информация для этой части полностью взята из этого источника, который я постараюсь популярно пересказать.

UEFI или Unified Extensible Firmware Interface стал эволюцией Legacy BIOS. В модели UEFI тоже есть базовая система ввода-вывода для взаимодействия с железом, хотя процесс загрузки системы и стал отличаться. UEFI использует GPT (Guid partition table). GPT тесно связана со спецификацией и является более продвинутой моделью для хранения информации о разделах диска. Изменился процесс, но задачи остались прежними: инициализация устройств ввода-вывода и передача управления в код операционной системы. UEFI не только заменяет бóльшую часть функций BIOS, но также предоставляет широкий спектр возможности для разработки в pre-OS среде. Хорошее сравнение Legacy BIOS и UEFI есть тут.

В данном представлении BIOS это компонент, обеспечивающий непосредственное общение с железом и является firmware. UEFI это унификация интерфейса железа для операционной системы, что существенно облегчает жизнь разработчикам.

В мире UEFI мы можем разрабатывать драйвера или приложения. Есть специальный подтип приложений — загрузчики. Разница лишь в том, что эти приложения не завершаются привычным нам образом. Завершаются они вызовом функции ExitBootServices() и передают управление в операционную систему. Чтобы принять решение какой же драйвер нужен вам, рекомендую заглянуть сюда, чтобы расширить понимание о протоколах и рекомендациях по их использованию.

Dev kits

Небольшой список того, что мы будем использовать в нашей практике:

(Extensible Firmware Interface Development Kit) — является свободно распространяемым проектом для разработки UEFI приложений и драйверов, которую и мы будем использовать, по началу не сильно в неё углубляясь. — проект облегчающий разработку в Visual Studio. Больше не нужно заморачиваться с .inf файлами и ковыряться в 100500 скриптах на Python. Все это уже сделано за вас. Внутри можно найти QEMU для запуска нашего кода. В проекте представлены примеры приложения и драйверов. — комплексный проект для firmware. Его задача — помочь разработать решение для старта железа и передачи управления в payload (например UEFI или GRUB), который в свою очередь загрузит операционную систему. В данной статье мы не будем затрагивать coreboot. Оставим его для будущих экспериментов, когда набью руку с EDKII. Возможно правильным вектором развития будет Coreboot + Tianocore UEFI + Windows 7 x64.

Последовательность загрузки

Коротко разберем через какие стадии проходит наша машина, прежде чем мы видим заветный логотип операционной системы. Для этого рассмотрим следующую диаграмму:

Ссылка

Процесс с момента нажатия на кнопку питания на корпусе и до полной готовности UEFI интерфейса называется Platform Initialization и делится он на несколько фаз:

Security (SEC) — зависит от платформы и процессора, обычно реализована ассемблерными командами, проводит первоначальную инициализацию временной памяти, проверку остальной части платформы на безопасность различными способами.
Pre EFI Initialization (PEI) — в данной фазе уже начинается работа EFI кода, главная задача — загрузка DXE Foundation который будет стартовать DXE драйверов на следующей фазе. На самом деле, тут происходит еще очень много всего, но то, что мы планируем разрабатывать, сюда не пролезет, так что двигаемся дальше.
Driver Execution Environment (DXE) — на данном этапе начинают стартовать драйвера. Наиболее важная для нас фаза, потому, что наш драйвер тоже будет запущен тут. Данная среда исполнения драйверов и является основным преимуществом над Legacy BIOS. Тут код начинает исполняться параллельно. DXE ведет себя на манер операционной системы. Это позволяет различным компаниям имплементировать свои драйвера. DXE Foundation, развернутый на предыдущей фазе, поочередно находит драйвера, библиотеки и приложения, разворачивает их памяти и исполняет.
После этой фазы эстафету принимает Boot Device Selection (BDS). Вы наверняка лично видели данную фазу. Тут происходит выбор на каком устройстве искать приложение — загрузчик операционной системы. После выбора начинается переход к операционной системе. DXE boot драйвера начинают выгружаться из памяти. Загрузчик операционной системы наоборот загружается в память с помощью блочного протокола ввода — вывода BLOCK_IO. Здесь не все DXE драйвера завершают свою работу. Существуют так называемые runtime драйвера. Им придется на понятной для загруженной операционной системе нотации разметить память, которую они занимают. Иными словами виртуализировать свои адреса в адресное пространство Windows, когда произойдет вызов функции SetVirtualAddressMap(). Как только среда будет готова, “Main” функция ядра ОС начнет исполнение, а фаза EFI завершится вызовом ExitBootServices(). Контроль полностью передан в операционную систему. Дальше Windows будет решать какие и откуда загрузить дайвера, как читать и писать на диск и что за файловую систему использовать. Картинка обобщающая вышеуказанную последовательность:

Ссылка

Классный рассказ о этапах загрузки есть тут.

Подготовка проекта

Пришло время поставить перед собой простую задачу. Мы можем загрузить наш драйвер в DXE фазе, открыть файл на диске и записать в него какие — нибудь данные. Задача достаточно простая, чтобы потренироваться.

Как я уже упоминал мы воспользуемся проектом VisualUEFI, однако рекомендую также попробовать способы описанные тут, хотя бы потому, что использовать дебагер легче в описанном по ссылке способе.

Допускаю, что у вас уже есть Visual Studio. В моем случае у меня Visual Studio 2019. Для начала клонируем себе проект VisualUEFI:

Соберем EDKII. Для этого открываем EDK-II.sln из \VisualUefi\EDK-II, и просто жмем build на решении. Все проекты в решении должны успешно собраться, и можно переходить к уже готовым примерам. Открываем samples.sln из \VisualUefi\samples. Жмем build на приложении и драйвере, после чего можно запускать QEMU простым нажатием F5.

Проверяем наш UefiDriver и UefiApplication, именно так называются примеры в решении samples.sln.

Отлично, драйвер не только собрался, но и успешно загрузился. Выполнив команду drivers, мы даже увидим его в списке.

Если бы в коде мы не возвращали EFI_ACCESS_DENIED в функции UefiUnload, мы бы даже смогли выгрузить наш драйвер, выполнив команду:

Теперь вызовем наше приложение:

Написание кода

Рассмотрим код предоставленного нам драйвера. Все начинается с функции UefiMain, которая находится в файле drvmain.c. Мы бы могли назвать точку входа и другим именем, если бы писали драйвер “с нуля”, указать это можно было бы в .inf файле.

В нашем примере, в функции UefiMain, происходит вызов функции EfiLibInstallDriverBindingComponentName2, которая регистрирует имя нашего драйвера и Driver Binding Protocol. Согласно модели драйверов UEFI, все драйвера устройств должны регистрировать этот протокол для предоставления контроллеру функций Support, Start, Stop. Функция Support отвечает, может ли наш драйвер работать с данным контроллером. Если да, то вызывается функция Start. Подробнее об этом хорошо описано в спецификации (раздел Protocols — UEFI Driver Model). В нашем примере функции Support, Start и Stop устанавливают наш кастомный протокол. Его реализация в файле drvpnp.c:

Фукнция EfiLibInstallDriverBindingComponentName2 реализована в файле UefiDriverModel.c, и, на самом деле, очень простая. Она вызывает InstallMultipleProtocolInterfaces из Boot Services (см. Спецификацию стр 210). Данная функция связывает handle (в нашем случае ImageHandle, который мы получили на точке входа) и протокол.

Соответственно, можно, и нужно, в момент выгрузки драйвера, удалить установленные компоненты. Мы сделаем это в нашей функции Unload. Теперь наш драйвер можно будет выгружать по команде unload , или перед передачей управления в операционную систему.

Как вы могли заметить, в нашем коде мы взаимодействуем с UEFI через глобальное поле gBS (global Boot Services). Также, существует gRT (global Runtime Services), а вместе они являются частью структуры System Table. Источник.

Для работы с файлами нам понадобится Simple File System Protocol (см. Спецификацию стр 504). Вызвав функцию LocateProtocol, можно получить на него указатель, хотя более правильный способ перечислить все handles на устройства файловой системы с помощью функции LocateHandleBuffer, и, перебрав все протоколы Simple File System, выбрать подходящий, который позволит нам писать и читать в файл. Пример такого кода тут. А мы же воспользуемся способом проще. У протокола есть всего одна функция, которая позволит нам открыть том.

Далее, нам необходимо уметь создавать файл и закрывать его. Воспользуемся EFI_FILE_PROTOCOL, в котором есть функции для работы с файловой системой (см. Спецификацию стр 506).

Для записи в файл нам придется вручную двигать каретку. Для этого будем спрашивать размер файла с помощью функции GetInfo.

Вызываем наши функции и пишем случайные данные в наш файл:

Есть альтернативный способ выполнить нашу задачу. В проекте VisualUEFI уже реализовано то, что мы написали выше. Мы можем просто подключить заголовочный файл ShellLib.h и вызвать в самом начале функцию ShellInitialize. Все необходимые протоколы для работы с файловой системой будут открыты, а функции ShellOpenFileByName, ShellWrite и ShellRead реализованы почти так же, как и у нас.

→ Код этого примера на github

Если мы хотим перейти в VMWare, то наиболее правильным будет модификация firmware с помощью UEFITool. Например тут демонстрируется как добавляют NTFS драйвер в UEFI.

Выводы

Усложнить идею нашего драйвера и ближе подвести его под требования проекта Active Restore можно следующим образом: открыть протокол BLOCK_IO, заменить функции чтения на диск нашими функциями, которые запишут данные, читаемые с диска в лог и затем вызовут оригинальные функции. Сделать это можно следующим образом:

Нужно будет не забыть подписаться на ExitBootServices(), чтобы вернуть указатели на место. После того, как фильтр файловой системы в Windows будет готов, минифильтр продолжит логировать чтение с диска.

Заметки об администрировании и программировании во FreeBSD.

вторник, 8 ноября 2011 г.

Ликбез по UEFI

Многие пользователи ПК имеют представление о том, что такое BIOS, для чего и как он работает. Но в последнее время появилась альтернатива, стремительно вытесняющая BIOS с наших ПК, а на серверном оборудовании уже прочно обосновавшаяся - это EFI и его более современный родственник UEFI.

Extensible Firmware Interface (EFI) впервые был предложен компанией Intel в качестве замены BIOS для своей новой 64-битной платформы IA64 (Itanium). Позднее Intel выпустила обновлённую спецификацию EFI 1.10, которая уже не привязывалась к платформе Itanium и могла использоваться для x86.

Чтобы труды Intel не пропали зря и народ обратил внимание на EFI был организован Unified EFI Forum, куда вошло несколько крупных компаний и который занялся дальнейшим развитием спецификации EFI. Чем он уже десять лет успешно занимается и на данный момент актуальной версией спецификации является UEFI 2.3.1.

Что же описывает эта спецификация? Честно говоря - МНОГО всего. Более 2000 страниц, и это только один из нескольких документов. UEFI firmware уже можно сравнивать с операционными системами. Для UEFI есть свои драйверы, свои сервисы и приложения. Даже есть свой шелл, который описан в отдельном документе UEFI Shell Specification. А вообще, конечно, идея правильная. Хорошо, когда всё стандартизовано и есть конкуренция, чего нельзя было сказать о BIOS.

Кстати, таблица GPT тоже описана в спецификации UEFI.

Итак, как же всё это работает? Разработчик аппаратной платформы пишет firmware, которая соответствует спецификациям UEFI и выполняет действия по описанным протоколам. Существует несколько инструментариев для разработчика связанных с UEFI компонентов. Некоторые из них - закрытые и коммерческие, некоторые - с открытым исходным кодом и свободно распространяемые. Разрабатывать firmware на ассемблере теперь нет нужды, хотя это тоже возможно. К интрументариям разработчика прилагаются все необходимые библиотеки и заголовочные файлы для разработки на языке Си. То же относится и к драйверам, и к EFI приложениям.

Так вот, эта firmware подобно BIOS помещается во flash память и в общем-то, цель у неё такая же - инициализировать оборудование для работы и передать управление операционной системе. Архитектурно она организована модульно и состоит из нескольких уровней, выполняющихся на различных этапах загрузки с момента включения питания. Подробную схему того, какие модули выполняются в какой момент времени, можно посмотреть в UEFI Platform Initialization Specification. Если в кратце, то это: предварительная инициализация памяти, процессоров, устройств и подготовка окружения для запуска следующих уровней firmware; загрузка драйверов устройств и запуск менеджера загрузки, который выполняет выбор устройства и запуск загрузчика операционной системы.

Для чего нужны драйверы? Драйверы должны поставляться производителями периферийных устройств. Они используются firmware для организации взаимодействия между устройством и UEFI приложением. С их помощью firmware может организовывать так называемые Runtime и Boot Services. Эти сервисы, в свою очередь, предоставляют набор функций, которые могут использовать UEFI приложения, сами драйверы, а так же загрузчик операционной системы.

Например, на сервере есть какой-то RAID контроллер с UEFI драйвером. Этот драйвер предоставляет базовые возможности доступа к содержимому своих RAID-массивов на блочном уровне через Boot Services. Т.е. например, загрузчик или какое-то другое UEFI приложение, используя определённые в спецификации API и протоколы, может прочитать информацию с тома RAID контроллера и, к примеру, выполнить загрузку ядра операционной системы. После загрузки ядро должно завершить работу с Boot Services и использовать свой полнофункциональный драйвер.

Другой пример - драйвер для сетевого адаптера может предоставить доступ к сети для загрузки операционной системы, либо для какого-то UEFI приложения, работающего с сетью. Эти драйверы могут предоставлять доступ к адаптеру не только в качестве Boot Services, но и как Runtime Services. Т.е. если у операционной системы нет драйвера для такого адаптера, то она может использовать стандартный API и продолжать работу с адаптером (на практике о таком использовании сетевых UEFI драйверов никто не слышал ;).

Вернёмся от драйверов к менеджеру загрузки. В его задачи входит выбор устройства загрузки и UEFI приложения в соответствии с настроенным порядком загрузки. Порядок определяется глобальными переменными из NVRAM, т.е. грубо говоря, настройками "BIOS". Например, если после инициализации UEFI firmware на сервере выбрать запуск меню настроек, то там отобразится список, порядок пунктов в котором будет выбран на основании этих самых глобальных переменных из NVRAM. В этом же списке могут оказаться дополнительные драйверы, загрузчики операционных систем, дополнительные UEFI приложения, найденные на EFI разделах дисков.

В спецификации UEFI в главе о таблице разделов GPT определены только два зарезервированных уникальных идентификатора GUID для типов разделов. Один из них используется для EFI System Partition. Этот раздел в таблице GPT используется для хранения дополнительных UEFI приложений, драйверов и загрузчиков операционных систем. Внутри этого раздела находится файловая система FAT с некоторыми дополнительными возможностями и требованиями. Сами же приложения представляют собой бинарники в формате PE/COFF (Microsoft Portable Executable and Common Object File Format).
Т.е. при желании можно смонтировать этот раздел и посмотреть, что там находится. Как, впрочем, и разместить там дополнительные приложения. Только необходимо поддерживать требуемую иерархию и именование файлов в файловой системе.

Дополнительные приложения могут выполнять самые разные функции. Например, это могут быть программы для диагностики оборудования, сетевые приложения, утилиты для работы с дисками и разделами, наконец - командный интерпретатор UEFI Shell.

Читайте также: