Чем ближе находится уровень абстракции приложения к реальному аппаратному обеспечению, тем больше возможностей как по управлению «железом», так и по доступу к недокументированным функциям.
Сейчас уже можно с определенной долей уверенности сказать, что эпоха DOS (Disk Operating System), в той классической реализации Microsoft/IBM, по которой многие её знают, ушла безвозвратно. Да, для своего времени — а это буквально всего лишь половина жизни одного поколения программистов — она была просто изумительна. Несмотря на кажущуюся простоту, DOSа была вполне эффективна для решения многих задач. А именно: для управления файлами, для работы с оперативной памятью (первоначально только в пределах первого мегабайта) и прямого доступа к портам ввода/вывода.
Иллюстрация из ранней документации к MS-DOS
В чем же заключалась изюминка такой простоты? А в том, что за счет отсутствия необходимости создавать различные уровни абстракций, у пользователя был прямой доступ к оборудованию. Это позволяло создавать приложения «раскручивающие железо» на все 100%. Конечно, никто не отменял деструктивных факторов — вирусной активности, некорректно спроектированного ПО и прочих неприятностей. Однако в большинстве случаев работа выполнялась точно и в срок.
Классический DOS:
архитектурные ограничения в 16 бит
Давайте вспомним, как вообще происходила загрузка рабочей станции в эпоху MS-DOS/PC-DOS/Dr-DOS. Первым делом отрабатывала POST (Power On Self Test) программа из ПЗУ, которую все привыкли называть BIOS — базовая система ввода и вывода (Basic Input/Output System). Инициализировались низкоуровневые подсистемы, в том числе, видео- и дисковые контроллеры. И затем управление передавалось непосредственно на загрузочное устройство, на котором в свою очередь находился MBR (Master Boot Record) — небольшая подпрограмма, решающая, что и откуда будет загружено. Под «что» подразумевается, конечно, операционная система, а под «откуда» — необходимый раздел на жестком диске.
Далее происходила посекторная загрузка драйвера, умеющего работать с форматом файловой системы, на которой и находились дальнейшие данные — в случае с реализацией DOS от компании IBM это был файл IBMBIO.COM [1] (или IO.SYS у Microsoft). И затем выполнялась подгрузка в оперативную память ядра самой Disk Operating System — исполняемого кода IBMDOS.COM (MSDOS.SYS).
Понятно, что в качестве формата файловой системы выступала FAT16. На фоне современных журналируемых систем NTFS/EXT4/ZFS она кажется настолько примитивной и со столькими ограничениями в архитектуре, что сейчас возникает закономерный вопрос — почему тогда не придумали что-либо получше? Ответ прост — не было объективной потребности. Более того, такая легкость внутренней архитектуры файловой системы позволяла быстро набросать и запрограммировать свой собственный файловый драйвер, благо вся его сложность заключалась в высчитывании секторных смещений по диску — для этого достаточно карандаша и простейшего наладоника.
За запуском ядра следовал старт командного процессора (COMMAND.COM), который, собственно, и предоставлял всю инфраструктуру перемещения по диску и управления файлами: команды copy, rename, cd, dir, type и т.д. В идеале, его наличие и не требовалось, если в конечном итоге предусматривалась работа только в одном единственном приложении. Но такое случалось достаточно редко, т.к. пользователям все-таки нужен был интерактивный режим.
Читатель готов уже спросить — хорошо, DOS был давным давно, у него были свои особенности, но, а причем теперь тут UEFI [2]? Предлагаю выделить красной линией, те элементы, из-за которых актуальность классического понятия DOS поднимается и востребована по сегодняшний день:
- наличие современной платформы (среды), которая обеспечивает почти прямой доступ к ресурсам ЭВМ, т.е. с минимальными уровнями абстракциями;
- позволяет сразу же работать в защищенном режиме (желательно 64-битном x86_64);
- располагает развитым API для управления ресурсами;
- запускается перед (!) операционной системой.
UEFI — открытая модульная структура взамен BIOS
Вроде бы ничего не приходит на ум, но… Давайте отмотаем немного назад и вспомним инициативу Intel, которая, начиная со середины 2000-х, стала активно продвигаться — использование на своих фирменных платах в качестве BIOS разработки Tiano, уходящей корнями чуть ли не во времена проектирования Itanium (это еще лет десять ранее), и ставившей перед собой цель обойти ограничения в виде 16-битного кода и быть аппаратно-независимым решением. Тогда, со средины 90-х до середины 2000-х она называлась просто как EFI (Extensible Firmware Interface). Затем большая часть документации и спецификаций были открыты, и реализация теперь известна под названием UEFI (Unified EFI). На настоящий момент порядка 170 производителей оборудования так или иначе используют UEFI, в том числе и конкурирующие разработчики BIOS. Так у Phoenix Technologies UEFI-совместимый продукт называется как SecureCore, у American Megatrends — Aptio, а Insyde Software позиционирует свое решение как InsydeH2O.
Архитектура UEFI
До момента открытия проекта Tiano на серверных платах Intel использовался де-факто корпоративный стандарт, разработанный компанией American Megatrends. В нем, несомненно, были и есть свои плюсы, но наличие лицензионных отчислений, я думаю, и послужило на каком-то этапе камнем окончательного преткновения. В итоге Intel решает идти своим путем, активнее инвестирует в собственное решение, и, заодно, косвенно финансирует компанию Insyde Software — разработчика BIOS с перспективными наработками, но для мобильной сферы (ноутбучное firmware). И компания не ошиблась. На сегодня UEFI BIOS — это самая правильная, самая перспективная и самая интересная реализация BIOS. Почему?
Схема загрузки UEFI
Во-первых, модульное решение. Если рассматривать внутреннюю компоновку EFI, видно, что её структура представляет в какой-то степени мини-операционную систему. В которой есть PEI-модули (Pre-EFI Initialization), которые настраивают различные аппаратные компоненты — чипсет, память, процессор — и в сумме называющиеся как PEI Core. Также присутствуют блоки с DXE-драйверами (Driver Execution Environment), которые и формируют ядро EFI.
Во-вторых, за счет открытости спецификаций можно проанализировать код и с очень большой степенью вероятности обнаружить, что «закладок» нет. Что имеется в виду под «закладкой» в случае с BIOS? Наличие небольшого SMM-супервизора, который работает в качестве мега-виртуализационной среды для любой операционной системы, работающей на любых следующих этапах загрузки рабочей станции — будь это VMware ESXi, Microsoft Hyper-V или любой другой baremetal-гипервизор. Важно то, что у SMM-супервизора и приоритет выше, и возможностей по своему сокрытию на порядок больше, т.к. он стартовал действительно на «чистом» железе.
В-третьих, за счет своей самодостаточности, UEFI можно рассматривать как законченное решение — полноценную операционную систему. А, следовательно, можно и нужно создавать такие важные продукты, как, например, антивирусные пакеты запускаемые с EFI-систем. Актуальность в них достаточно высока, т.к. UEFI, с учетом функции безопасной загрузки, предоставляет высокий класс защиты. Это, в свою очередь, является гарантией, что среда запуска по-настоящему чистая и антивирус в состоянии будет избавить от максимально возможного количества зловредов на носителях с эксплуатирующейся, но еще не запущенной операционной системой.
Стадии передачи управления
В качестве еще одного применения, EFI-систему можно рассматривать в качестве современного полигона для разработки полноценных 64-битных приложений, работающих в защищенном режиме. Если ранее, в DOS программисты были изначально ограничены 16-битовой адресацией, что накладывало трудности при выделении большого блока ОЗУ — требовалось открывать линию A20 и использовать защищенный режим процессора (для систем на базе архитектуры i386), то сейчас открываются широчайшие возможности. Прямая линейная адресация памяти, использование 64-битных ассемблерных команд. Добавьте широкий API-стек EFI-расширений и … далее все зависит уже от полета вашей фантазии.
Ссылки
[1] http://en.wikipedia.org/wiki/IBMBIO.COM
[2] http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface