Прощай, DOS!

Чем ближе находится уровень аб­ст­рак­ции при­ло­же­ния к ре­аль­но­му ап­па­рат­но­му обес­пе­че­нию, тем боль­ше воз­мож­но­стей как по уп­рав­ле­нию «же­ле­зом», так и по до­сту­пу к не­до­ку­мен­ти­ро­ван­ным фун­к­ци­ям.

Сейчас уже можно с определенной долей уве­рен­но­с­ти ска­зать, что эпо­ха DOS (Disk Ope­rat­ing Sys­tem), в той клас­си­че­ской ре­а­ли­за­ции Micro­soft/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 поднимается и востребована по сегодняшний день:

1. наличие современной платформы (среды), которая обеспечивает почти прямой доступ к ресурсам ЭВМ, т.е. с минимальными уровнями абстракциями;
2. позволяет сразу же работать в защищенном режиме (желательно 64-битном x86_64);
3. располагает развитым API для управления ресурсами;
4. запускается перед (!) операционной системой.

UEFI — открытая модульная структура взамен BIOS

Вроде бы ничего не приходит на ум, но… Давайте отмотаем немного назад и вспомним инициативу Intel, которая, на­чи­ная со середины 2000-х, стала активно продвигаться — использование на своих фирменных платах в качестве BIOS разработки Tiano, уходящей корнями чуть ли не во времена проектирования Itanium (это еще лет десять ранее), и ста­вив­шей перед собой цель обойти ограничения в виде 16-битного кода и быть аппаратно-независимым решением. Тог­да, со сре­ди­ны 90-х до середины 2000-х она называлась просто как EFI (Extensible Firmware Interface). За­тем боль­шая часть документации и спецификаций были открыты, и реализация теперь известна под названием UEFI (Unified EFI). На настоящий момент порядка 170 производителей оборудования так или иначе используют UEFI, в том числе и кон­ку­ри­ру­ю­щие разработчики BIOS. Так у Phoenix Technologies UEFI-совместимый продукт называется как SecureCore, у Ame­ri­can Me­ga­trends — Aptio, а Insyde Soft­ware позиционирует свое решение как InsydeH₂O.

Архитектура UEFI

До момента открытия проекта Tiano на серверных платах Intel использовался де-факто корпоративный стандарт, раз­ра­бо­тан­ный компанией American Megatrends. В нем, несомненно, были и есть свои плюсы, но наличие лицензионных отчислений, я думаю, и послужило на каком-то этапе камнем окончательного преткновения. В итоге Intel решает идти своим путем, активнее инвестирует в собственное решение, и, заодно, косвенно финансирует компанию Insyde Soft­ware — разработчика 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