legal note
IC Book © 2001

hardware
software

support
buy

Home page
   




Press
Прощай DOS, здравствуй UEFI
 


Сейчас уже можно с определенной долей уверенности сказать, что эпоха DOS (Disk Operating System), в той классической реализации Microsoft/IBM, по которой многие её собственно и знают, ушла безвозвратно. Да, для своего времени — а это буквально всего лишь половина жизни одного поколения программистов — система была просто изумительна. Несмотря на кажущуюся с первого взгляда простоту, она была вполне эффективна для решения многих задач. А именно: управление файлами, работа с оперативной памятью (первоначально только в пределах первого мегабайта), прямой доступ к портам ввода/вывода и т.п.

В чем же заключалась изюминка такой простоты? А в том, что за счет отсутствия необходимости создавать различные уровни абстракции, у пользователя был прямой доступ к оборудованию. За счет этого можно было создавать приложения раскручивающие железо на все 100%. Конечно, никто не отменял наличия деструктивных факторов — вирусной активности, неправильно спроектированного ПО и прочих неприятных моментов. Однако в большинстве случаев работа выполнялась корректно и быстро.

Давайте вспомним, как вообще происходила загрузка рабочей станции в эпоху MS-DOS/PC-DOS/Dr-DOS. Первым делом отрабатывала POST (Power On Self Test) программа из ПЗУ и которую все и привыкли называть как BIOS (Basic Input/Output System). Инициализировались низкоуровневые подсистемы, в том числе, видео- и дисковые контроллеры. И затем управление передавалось непосредственно на загрузочное устройство, на котором в свою очередь находился MBR (Master Boot Record) — небольшая подпрограмма, решающая, а что и откуда будет загружено далее. Под "что" подразумевается, конечно, операционная система, а под "откуда" — необходимый раздел на жестком диске. Далее происходила посекторная загрузка драйвера, умеющего работать с форматом файловой системы, на которой и находились дальнейшие данные — в случае с реализацией DOS от компании IBM это был файл IBMBIO.COM (IO.SYS для Microsoft). И затем следовала подгрузка в ОЗУ ядра самой Disk Operating System - IBMDOS.COM (MSDOS.SYS). Понятно, что в качестве формата файловой системы выступала FAT16. На фоне современных журналируемых систем NTFS/EXT4/ZFS она кажется настолько примитивной и со столькими ограничениями в архитектуре, что сейчас возникает закономерный вопрос — почему тогда не придумали что-либо лучшее? Ответ прост — не было объективной потребности. Более того, такая легкость внутренней архитектуры файловой системы позволяла быстро набросать и запрограммировать свой собственный файловый драйвер, благо вся его сложность заключалась в высчитывании секторных смещений по диска — хватит карандаша и простейшего наладонного калькулятора.

За запуском ядра следовал старт командного процессора (COMMAND.COM), который, собственно, и предоставлял всю инфраструктуру перемещения по диску и управления файлами: команды copy, rename, cd, dir, type и т.д. В идеале, его наличие и не требовалось, если в конечном итоге предусматривалась работа только в одном единственном приложении. Но такое случалось достаточно редко, т.к. пользователям все-таки нужен был интерактивный режим.

Читатель готов уже спросить — хорошо, DOS был давным давно, у него были свои особенности, но, а причем теперь тут UEFI? Предлагаю выделить красной линией, те элементы, из-за которых актуальность того классического понятия 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.

До момента открытия проекта Tiano на серверных платах Intel использовался де-факто корпоративный стандарт BIOS, разработанный компанией American Megatrends. В нем, несомненно, были и есть свои плюсы, но наличие лицензионных отчислений, я думаю, и послужило на каком-то этапе камнем окончательного преткновения. В итоге Intel решает идти своим путем, активнее инвестирует в собственное решение, и, заодно, косвенно финансирует компанию Insyde Software — разработчика BIOS с перспективными наработками, но для мобильной сферы (ноутбучное firmware). И компания не ошиблась. На сегодня UEFI BIOS — это самая правильная, самая перспективная и самая интересная реализация BIOS. Почему?

Во-первых, модульное решение. Если рассматривать внутреннюю компоновку 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-расширений и …далее зависит уже от полета вашей фантазии.

В роли командного интерпретатора EFI Shell

Когда чуть ранее мы упоминали, что командный интерпретатор DOS под названием COMMAND.COM в принципе не нужен, т.к. его роль — это организация интерактивного режима, то данный факт практически никогда не реализовывался на практике и интерпретатор всегда был в системе. Для UEFI же присущ диаметрально другой подход — нужно обеспечить, прежде всего, выполнение загрузчика операционной системы, поэтому наличие промежуточного интерактивного приложения скорее вредит, чем помогает. Поэтому EFI Shell формально существует в природе, но фактически внутри firmware его нет. Что, однако, не означает невозможность его запуска — отнюдь. Поместив на USB-носитель в раздел /boot/EFI/ файл EFI Shell под стандартным названием bootx64.efi, мы получаем реинакарнацию DOS-системы, но на современный лад.


Материал предоставлен сайтом «Железо» 10 июля 2014 г.





about
press


вверх