
Когда ранее мы упоминали, что командный DOS-интерпретатор под названием COMMAND.COM в принципе не нужен, так как его роль — это организация интерактивного режима, то данный факт практически никогда не реализовывался на практике и интерпретатор всегда был в системе. Для UEFI же присущ диаметрально другой подход — нужно обеспечить прежде всего выполнение загрузчика операционной системы, поэтому наличие промежуточного интерактивного приложения скорее вредит, чем помогает.
В роли командного интерпретатора – EFI Shell
Поэтому EFI Shell формально существует в природе, но фактически внутри firmware его нет. Что, однако, не означает невозможность его запуска — отнюдь. Поместив на USB-носитель в раздел \boot\EFI\ файл EFI Shell под стандартным названием bootx64.efi, мы получаем реинкарнацию DOS-системы, но на современный лад. Чтобы не быть привязанным к реальной аппаратуре и обезопасить себя от возможных негативных последствий, я предлагаю дальнейшие действия перенести в эмулированную среду и продолжить знакомство с EFI Shell на примере QEMU и специально адаптированным для него Tianocore BIOS [3].
Итак, забираем архив с Tianocore BIOS, распаковываем в текущий каталог и запускаем эмулятор как:
/usr/local/qemu-1.6/bin/qemu-system-x86_64 -L
Ключ «-L» означает, что видео- и BIOS-файлы хранятся в текущей директории. Сам файл EFI Shell интегрирован в образ BIOS.

Командная строка EFI Shell напоминает CLI-интерфейс от DOS
Запустив командный интерпретатор EFI, убеждаемся в первом впечатлении — очень похоже на старые, добрые дни MS-DOS. Есть встроенная справка (интегрированная в Shell команда help), присутствует текстовый редактор, который теперь умеет редактировать ASCII и UTF8-файлы, и ряд других команд. Однако, внедрение открытых технологий не могло повлиять и на развитие UEFI. В числе команд замечаем также специфичные команды вида mount и load. Соответственно, означающие монтирование раздела и загрузку в память драйвера к устройству. Очень похоже на BSD- и Linux-системы, не правда ли?

Загрузка интерпретатора UEFI осуществляется силами UEFI Boot менеджера
Дабы ощутить всю мощь EFI, создадим файловый образ с GPT-таблицей. А в нем сделаем 2 раздела: один в формате FAT16, понятный для встроенных драйверов EFI, а другой отформатируем в EXT2, но с прицелом его монтирования из-под самой микро-ОС UEFI
$ parted ./hdcblk
WARNING: You are not superuser. Watch out for permissions.
GNU Parted 2.3
Using /home/anton/efi/hdcblk
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) Unit
Unit? [compact]? B
(parted) print
Model: (file)
Disk /home/anton/efi/hdcblk: 157286400B
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1048576B 52428799B 51380224B primary fat16 boot, lba
2 52428800B 157286399B 104857600B primary ext2
(parted) quit
Листинг 1. Определяем смещение внутри GPT-таблицы
Определим смещение и монтируем первый раздел в виде loop-устройства. Кладем необходимые драйверы и готовые EFI-приложения и запускаем QEMU заново. Перед нами примонтированный раздел FAT16, переход на него осуществляется как: «fs0:»
Проверим командой map, какие разделы еще примонтированы, но видим только еще одно блочное устройство. Всё верно, в DXE пространстве ведь нет драйвера для EXT2-разделов.

EFI-приложение можно тестировать через интерфейс Boot Maintenance Manager
Загрузим и примонтируем наш раздел с помощью ext2-драйвера с проекта rEFInd, т.е. выполним последовательно команды по одной на каждую строку: «load ext2_x64.efi», «mount blk3 fs1», «fs1:», «dir». Убеждаемся, что раздел успешно примонтирован.
Отлично, теперь у нас есть доступ практически к любой файловой системе, благо EFI-драйверы к ним уже созданы. А это означает, что не за горами создание не только аналога Volkov Commander для EFI-среды, но также и сервисных утилит и приложений — тот же антивирусный пакет, портирование текстовых (и графических!) приложений (например, браузер links) и многое другое. С учетом того, что перед нами изначально безопасная и чистая среда, то перед нами действительно любопытные перспективы. Выглядят заманчиво? Еще бы!

Практически любая файловая система может быть смонтирована с помощью EFI-драйверов
Как и на чем создавать EFI-приложения?
Может создаться обманчивое впечатление, что EFI-приложение — это безумно сложное программирование. Но это не так. Для создания приложений требуется компилятор, который умеет создавать объектный код в формате PE32. И среда разработчика EDK II (EFI Development Kit) / UDK2010 (UEFI DevKit) [6]. Несмотря на то, что спецификации открыты и код лицензируется под BSD-лицензией и даже принимаются от пользователей апстрим-изменения в EDK II, среда UDK считается стабильной и эталонной для производителей материнских плат, т.к. разрабатывается и поддерживается компанией Intel.

Формат EFI-приложения должен соответствовать стандарту PE32
Среда разработчика существует как для Linux, так и для систем на базе Windows и Mac OS X. Сборка обеспечивается, как правило, компиляторами GCC и нативными из состава Visual Studio 2008 и Xcode. Хотя повторюсь – фактически, достаточно будет только компилятора и заголовочных файлов EDK. Данный факт особенно актуален, если принято решение задействовать ассемблер, а именно flatasm [4]. В этом случае получится создавать наиболее оптимизированный и минимальный код. Конечно, при росте проекта имеет смысл переориентироватьмся на C/C++ и переходить, соответственно, на EDK.
Более подробно на создании EFI-приложений остановимся в следующих публикациях, а пока отмечу, что приложение вида «Hello, World» на ASM занимает всего 50 строк. Компилируется FlatASM на станции с Core2Duo за 1 микросекунду и занимает только 2 Кб.
Выводы
С точки зрения дальнейшего развития подсистемы низкоуровневого аппаратного обеспечения (BIOS) появление открытого решения, похожего на EFI, кажется закономерным и не случайным. Появляются серверные и десктопные платформы на основе разных процессорных архитектур (x86_64, ARM, IA64), чипсетов и интегрированных устройств, например, организующих шифрование (чипы TPM). Для организации всего этого сонма в единое целое требуется модульный конструктор, которым могли бы пользоваться как конечные производители, так и изготовители отдельных аппаратных модулей. К счастью, насущность этой проблемы первой увидела Intel и представила такое открытое решение как UEFI. К вящей радости программистов системного ПО, т.к. при ближайшем рассмотрении указанное решение является настоящей микро-операционvной системой с практически неограниченными возможностями по управлению как аппаратной частью, так и загружаемой в дальнейшем реальной ОС — будь это Windows, BSD, Linux или нечто аналогичное. А применения этим возможностям открываются самые широкие.
Ссылки
[3] http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF
[4] http://flatassembler.net/