uefi вместо bios: как установить, на пк

⇡#мягкое выдавливание конкурентов

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

Кое-где угроза была воспринята настолько серьезно, что, например, в Австралии Linux-сообщество тут же запустило процедуру подачи официальной жалобы в ACCC, Австралийскую комиссию по честной конкуренции и правам потребителей.

Однако, как говорят сведущие в технических и юридических тонкостях специалисты, именно из этого разбирательства Microsoft практически наверняка сумеет выбраться без всяких проблем. Просто потому, что в описании процесса безопасной загрузки UEFI или, точнее, в словах о необходимости такого процесса корпорацией не упоминаются иные операционные системы.

Суть проблемы, с которой сражается Microsoft (очень тщательно и аккуратно подбирая выражения), — это борьба с вредоносными кодами, а безопасная загрузка тем и хороша для работы Windows, что такой процесс перекрывает еще один опасный канал для проникновения вредоносных программ.

Есть ощущение, что с выходом Windows 8 увидеть на экране какой-то другой интерфейс станет посложнее. По крайней мере, для людей, не умеющих собирать компьютеры самостоятельно

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

Начиналось все так. В конце сентября один из ведущих разработчиков дистрибутива Red Hat Мэтью Гаррет (Matthew Garrett) в своем блоге отметил, что, согласно новым правилам относительно присвоения машинам логотипа «Windows 8», все компьютеры, совместимые с этой ОС, должны будут иметь для загрузки уровень UEFI вместо устаревшего уровня BIOS.

Причем речь шла не просто о любом уровне спецификаций UEFI (реализованных в разных версиях достаточно давно), а конкретно о безопасном UEFI. Что означает более жесткий контроль за процессом загрузки системы. Конкретнее, это ужесточение означает то, что «все микрокоды прошивки и программное обеспечение, участвующее в процессе загрузки, должны быть криптографически подписаны доверяемым органом сертификации (CA)» — согласно слайдам презентации о загрузочном процессе UEFI в одном из официальных докладов Ари ван дер Ховена (Arie van der Hoeven), главного менеджера программ Microsoft (здесь, наверное, стоит привести и английскую версию названия этой почти непереводимой должности, Principal Program Manager Lead. — прим. редакции).

Именно этот момент — безопасная загрузка — ставит Linux в довольно непростую ситуацию. Потому что он означает, что теперь для «загружаемости» на одной из всех таких «Windows 8»-одобренных машин соответствующий дистрибутив Linux должен иметь сертифицированные криптоключи от конкретного изготовителя компьютера.

С чисто технической точки зрения, как пояснил Гаррет в одном из следующих блог-постов, это означает, что на получение такого рода ключей разработчикам любого Linux-дистрибутива потребуется убить порядка недели на переговоры-соглашения с каждым из производителей железа индивидуально.

Судя по всему, коварство Microsoft всерьез потрясло Мэтью Гаррета, так что на всех новых фотографиях он выглядит одинаково удивленным

Ну, к словесным баталиям деятелям мира Linux не привыкать. Однако процедура оказывается чрезвычайно запутанной и трудозатратной — даже для линуксоида со стажем — сразу в двух аспектах: юридическом и практическом.

Во-первых, юридическая сторона. По свидетельству Гаррета, самый распространенный линуксовский загрузчик GRUB 2 лицензирован на условиях лицензии GPLv3. Это вроде бы может означать, что ключи должны быть предоставлены поставщиком вместе с исходным кодом программы.

Однако в действительности это весьма мутный момент. Лицензия GPLv3 требует, чтобы ключи цифровой подписи выпускались, когда аппаратное обеспечение продается вместе с ПО, созданным под GPLv3 (и криптографически подписанным). Но если это же подписанное ПО просто используется на чьем-то еще аппаратном обеспечении, тогда ключи не требуются.

И хотя уже это выглядит запутанно, ситуация еще более сложна, когда речь идет о GPLv2, лицензии для первоначального загрузчика GRUB (существенно отличающейся в своих требованиях от GPLv3). Для того чтобы полностью избавиться от всех этих юридических неясностей, Гаррет рекомендует просто использовать иной загрузчик, не связанный условиями лицензии GPL.

Вот только гарретовский рецепт, как бы сомнительно он ни выглядел, в реальности может оказаться еще опаснее. Процедура загрузки ОС — это один из сервисов, которые уже встроены в ядро Linux. А ядро этой ОС является кодом, работа с которым определяется лицензией GPLv2, причем ситуацию эту даже не собираются менять — из неких принципиальных соображений и несогласия с GPLv3.

Преимущества дисков GPT перед MBR

Как BIOS UEFI пришла на смену обычной BIOS, так и GPT (стандарт таблицы разделов GUID Partition Table, отсюда, собственно, и аббревиатура GPT) является более совершенной альтернативой стандарта-предшественника – главной загрузочной записи MBR. Единственное, в чем пока еще выигрывает MBR – это в совместимости.

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

С GPT-дисков могут загружаться только компьютеры с BIOS UEFI, а устанавливаются на эти диски только 64-битные редакции Windows Vista, 7, 8.1, 10 и соответствующие им серверные редакции. Mac OS X и Linux также могут загружаться с GPT-дисков. Windows XP читает данные с GPT-диска, если он подключен в качестве дополнительного носителя, но загружаться с такого диска эта версия системы не умеет.

На совместимости со старым компьютерным оборудованием и старыми операционными системами преимущества MBR заканчиваются. Тогда как у GPT-дисков плюсов гораздо больше, в их числе:

  • Использование жестких дисков с объемом более 2 Тб (у MBR максимум 2,2 Тб);
  • Возможность формирования разделов с объемом 18 Эбайт (18 тыс. Тб);
  • Возможность создать на диске 128 первичных (основных) разделов, с которых будут загружаться операционные системы (у MBR только 4);
  • Хранение нескольких копий данных по всему жесткому диску, что обеспечивает в сравнении с MBR большее быстродействие при работе с данными и лучший результат при их восстановлении.

Из всех названных преимуществ реальную пользу для обычных пользователей несет лишь последнее, но его одного хватит в качестве аргумента для использования стиля разметки диска GPT, если в наличии имеется компьютер на базе BIOS UEFI, но операционная система и данные находятся на MBR-диске.

Bios против uefi

BIOS — это система, которая отвечает за все операции ввода/вывода для Windows. Разработана она была в далеком 1981 году, т.е. существует уже 33 года. Самый первый вариант BIOS, который использовался на компьютерах IBM, естественно, сильно отличался от сегодняшнего варианта.

:/>  Как отключить режим «В самолете» на Windows 10 на компьютере или ноутбуке?

Но со временем компьютер и вся периферия постепенно совершенствовались, и BIOS уже не мог выполнять те задачи, которые ему приписывали изначально. Так появились драйверы и разные программы, которые взаимодействовали с операционной системой. С годами BIOS постоянно менялся, пытаясь адаптироваться под новую технику, и в начале 90-х годов он уже мог выполнять такие функции, как автоматическая настройка плат расширения, загрузка с DVD-привода и т.д.

А новый вариант BIOS UEFI начал разрабатываться 13 лет назад, с 2001 года. Разработкой занималась компания Intel, которая собиралась использовать такой BIOS только для серверного процессора Itanium. Дело в том, что на этом процессоре не работала никакая версия BIOS, и даже доработки данного интерфейса не помогали в этой ситуации.

Именно это и послужило стимулом для разработки BIOS UEFI. Изначально этот интерфейс назывался EFI, а первой компанией, которая начала его использовать, стала Apple. Корпорация Apple с 2006 года начала собирать компьютеры и ноутбуки на базе процессоров Inter и BIOS EFI. А за год до этого к аббревиатуре EFI добавилась буква «U», под которой скрывалось слово «Unified».

Данное слово обозначает, что разработкой UEFI BIOS занималось одновременно несколько компаний. К ним относятся IBM, Dell, HP, Phoenix Inside, а также, естественно, компания Microsoft, поскольку именно она является основным разработчиком операционных систем.

Алгоритм работы uefi

В разрез с BIOS, хранилищем параметров UEFI является не ПЗУ, а энергонезависимая общая оперативная память с произвольным доступом (NVRAM). Она обычно включает статическую память SRAM с собственной батарейкой, но может допускать работу в связке, например, с флеш-памятью.

Заданные конфигурации системы UEFI хранятся в специальном файле с расширением efi в NVRAM или в системном разделе накопительного устройства (ESP). Этот же раздел содержит ПО загрузчика установленной ОС. Данные хранятся в виде переменных с атрибутами «наименование параметра» = «значение», которые включают множество характеристик. Они доступны не только инженерам-разработчикам, но и владельцам компьютеров.

Если задача BIOS заключалась в отыскании главной загрузочной записи (MBR) на носителе первичной информации и трансляции управления операционной системе, то последовательность действий последней подсистемы иная. Эта модель опирается на индивидуальный загрузчик UEFI Boot Manager с полноценными функциями в виде стандартного модуля. Он отличается своей структурой и сохраняется в запоминающем элементе типа NVRAM.

Модулю Boot Manager’a присущ обширный комплект инструкций, но среди их множества выделяются UEFI-образы: загрузчики ОС начального этапа, драйверы и приложения. Для установки операционной системы пригоден какой-либо образ, сохраненный на разного рода физических носителях.

Глобальный массив модуля BootOrder содержит переменные дескрипторов загрузки вида Boot####.  За каждым элементом закреплен какая-то определенная физическая загрузочная компонента или даже файл в виде образа UEFI, находящийся на ней.

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

Полный алгоритм функционирования интерфейса в конечном итоге включает в себя 4 фазы с ужесточенными правилами для любой. Первые три процесса (SEC, PEI, DXE) готовят условия непосредственно для загрузчика ОС. Последняя фаза (BSD) отвечает за работу собственно самого загрузчика операционной системы.

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

UEFI (Unified Extensible Firmware Interface, единый интерфейс расширяемой прошивки) — это небольшая операционная система, которая начинает работать при включении компьютера. Она пришла на замену устаревшей модели BIOS. UEFI позволяет унифицировать процесс разработки и создавать отдельные модули, а не только прошивку целиком.

Фреймворк имеет хорошо читаемый и документированный код на C. Многие пользователи отмечают удобный интерфейс, который разрешает пользоваться мышью. Среди других преимуществ платформы — поддержка сети «из коробки» и возможность работать с дисками объемом более 2 ТБ. Все это позволяет ускорить процесс разработки и сделать его безопаснее.

Интерфейс UEFI
Интерфейс UEFI

По требованиям платформы диск должен быть размечен в формате GPT. Соответственно, длина адреса блока будет равна 64 битам. Опираясь на эти данные, давайте вычислим гипотетический размер диска, который можно адресовать с помощью этого формата. Если использовать сектор размером 512 байтов, получим более 9 зеттабайт.

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

Высокоуровневый взгляд на UEFI
Высокоуровневый взгляд на UEFI

Приложения и драйвера UEFI имеют две таблицы для работы с API-интерфейсом — EFI Boot Services Table (службы доступны в процессе загрузки) и EFI Runtime Services Table (службы доступны и в процессе загрузки, и в процессе работы ядра ОС). API-интерфейс необходим, чтобы взаимодействовать с оборудованием, выделять память и выполнять другие простые функции по аналогии с WinAPI.

EFI Boot Services Table и EFI Runtime Services Table
EFI Boot Services Table и EFI Runtime Services Table

Как мы уже говорили ранее, прошивку UEFI можно дополнять модулями. Утилита UEFI Tool позволяет парсить файлы прошивок различных вендоров. Например, файл прошивки Asus содержит множество драйверов и модулей. С помощью этой утилиты в процессе разработки можно менять, удалять или добавлять модули в зависимости от случая.

Файл прошивки Asus, открытый в UEFI Tool
Файл прошивки Asus, открытый в UEFI Tool

Напомним схему цепочки программ в Legacy BIOS (ее мы рассматривали в прошлой статье).

Загрузка в режиме BIOS
Загрузка в режиме BIOS

При переходе к UEFI такие компоненты, как MBR и VBR, исчезают, и их функции частично берут на себя другие модули.

Загрузка в режиме UEFI
Загрузка в режиме UEFI

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

Код UEFI достаточно сложный. Он включает семь стадий работы прошивки: Security, Pre-EFI Initialization, Driver Execution Environment, Boot Device Selection, Transient System Load, Runtime и Afterlife. Что интересно, работа на стадии SEC происходит во временной памяти, формирующейся из кэша процессора. На этом уровне прошивка становится корнем доверия всей системы.

На стадии DXE выполняются DXE-драйверы для устройств. Именно на данном этапе злоумышленникам удобнее всего встраивать вредоносные сущности в полезную нагрузку. BDS — стадия выбора загрузочного устройства, которое отвечает за запуск ОС. Runtime — стадия работы ОС. Afterlife — стадия завершения работы компьютера.

Знакомьтесь: mosaicregressor

Еще один интересный буткит — MosaicRegressor, исследованный специалистами «Лаборатории Касперского». В его случае начальный вектор заражения неизвестен, то есть никто не знает, как буткит был установлен.

Состав MosaicRegressor
Состав MosaicRegressor

В зараженной прошивке исследователи обнаружили четыре модуля, два драйвера и два приложения, исполняющих вредоносную нагрузку. Рассмотрим их подробнее. Первым исполняется модуль SmmInterfaceBase. В его задачу входит создание c помощью API-функции CreateEventEx события EVENT_GROUPR_READY_TO_BOOT.

:/>  Как включить или отключить игровой режим в Windows 10
Состав модулей MosaicRegressor
Состав модулей MosaicRegressor

Интересно, что происходит внутри callback? Давайте посмотрим. С помощью уникального идентификатора приложения (GUID) обнаруживается модуль SmmAccessSub. Затем он запускается.

Модуль SmmAccessSub
Модуль SmmAccessSub

В этом модуле SmmAccessSub, по нашему мнению, довольно тривиальный подход к persist. Он заключается в сбросе пользовательского модуля в папку Startup. При этом никаких действий с драйверами или подмен не происходит. 

Еще одним модулем в зараженной прошивке был SmmReset. Он сбрасывает значение EFE до нуля.

Модуль SmmReset
Модуль SmmReset

Буткит MosaicRegressor не использует SmmReset, однако модуль для работы с точно такой же переменной есть в утекшем репозитории Hacking Team и применяется, чтобы определить, заражена прошивка или нет.

Напоследок

uefi вместо bios: как установить, на пкКусочек запроса из CHIPSEC. Где учат таким таинствам?

Как уже было сказано, разработка и внедрение в оболочке UEFI – процесс увлекательный и креативный. Всегда можно столкнуться с чем-то новым даже на известном поле. С одной стороны, радует, что стандарт развивается, с другой – огорчает, что конкретные его реализации производителями получаются слишком «творческими».

Основными проблемами были и остаются:

  1. Отход вендоров от спецификации UEFI при разработке прошивки.
  2. Ошибки в коде при реализации.
  3. НДВ в коде, всплывающие при интеграции.

И последнее, но не маловажное – отсутствие многих вещей в официальной (читай, открытой) документации, таких как, например, описаний протокола общения с ME через PCI устройства типа MEI, HECI. Можно найти описание регистров, но не команд. Найти GUID, но не его назначение.

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

Владимир Онипчук,Руководитель группы программно-аппаратных средств защитыООО «Газинформсервис»

Платформозависимость

uefi вместо bios: как установить, на пк

Первое, что необходимо выяснить при интеграции в платформу – сможем ли мы с ней работать? Версия спецификации UEFI важна, и на большинстве устройств она представлена в диапазоне между 2.1 и 2.7. Более новое пока не попадало на исследовательский стенд.

Более старое встречается, и его работоспособность может быть ограничена из-за отсутствия нужных протоколов или криво написанных для их реализации драйверов. Например, часто не хватает UnicodeCollation, при обращении к smbios возникают недокументированные ошибки, не работают функции смены языка через SetVariable().

Ещё в нашей практике посчастливилось наткнуться на два мини-компьютера с Intel Bay Trail D и 32-разрядной прошивкой на борту. Случай редкий, но в своё время вызвал необходимость экстренно перекомпилировать модули. Собственно, как и вопрос: встретимся ли мы с более современной платформой такой же разрядности в будущем? А если встретимся, то где?

Следующий шаг – определение способа интеграции. Модули встраиваются в прошивку, прошивка находится в SPI-микросхеме на плате, там же неподалёку располагается PCH с Intel ME. И тут возникает самый интересный вопрос – а как туда достучаться? Старый добрый программатор с «крокодилом» — это хорошо, это надёжно.

Даже если не зацепится до конца, всегда можно посмотреть на горящие светодиоды на плате, питания с программатора для них вполне хватает. Работает почти безотказно, за исключением некоторых старых моделей HP, где микруха SOIC-16 с прошивкой находится в такой доступности, что проще исхитриться и припаять к ее ногам переходник, чем протискивать клипсу.

uefi вместо bios: как установить, на пк
uefi вместо bios: как установить, на пк
Знаю, что на Хабре есть люди, сделавшие вклад в написание flashrom’а, им отдельное спасибо.

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

FPT (Flash programming tool) из комплекта Intel (CS)ME System Tools, и AFU (AMI Firmware Update) для Aptio от American Megatrends. Эти утилиты запускаются как из среды EFI, так из операционных систем Windows, Linux, DOS. Утилиты в чём-то взаимозаменяемые, обе позволяют считать образ если не целиком, то определенные регионы уж точно. И иногда даже позволяют записать обратно.

uefi вместо bios: как установить, на пк
uefi вместо bios: как установить, на пк
Пишет и не пишет

Тут и появляется первый серьёзный камень преткновения на пути интеграции. Далеко не все материнские платы позволяют считать прошивку целиком, запрещая доступ к региону ME (ME – почти святое, Интел его читать по-хорошему не разрешит, а по-плохому мы не всегда хотим).

Ещё меньше – залить что-то даже в регион BIOS, если только это не подписанная капсула. Вероятность успеха сильно разнится в зависимости от производителя и свежести чипсета. На некоторых моделях материнских плат можно пронаблюдать забавную картину: то, что не записывалось на старых платах вендора, на новых влетает враз.

Иногда бороться с защитой от записи помогает парсер IFR, приоткрывающий нам завесу над скрытыми настройками и переменными. А иногда помогает только хардкор – джампер, открывающий доступ на запись или «выключающий» ME (если таковой предусмотрен, конечно).

Проблематика работы с аппаратными протоколами

uefi вместо bios: как установить, на пк

Отдельные проблемы всплывают, когда начинаем работать с USB-устройствами – накопителями и токенами. Происходит это зачастую потому, что код BIOS для работы с периферией – это опасный коктейль из драйверов и приложений от Independent Hardware Vendor (IHV) под конкретную периферию, кода от производителя чипсета (в нашем случае – от Intel), кода от производителя BIOS и кода от производителя материнской платы.

Возникали следующие «интересные» ситуации:

Токен «не обнаружен». При этом на нём горит LED. Вероятно, не проходит процедура начального сброса USB-устройства хост-контроллером, то есть питание подано, но сброс через изменение линий D и D- не отрабатывает правильно, а без него любые дальнейшие манипуляции с токеном бессмысленны.

Компьютер зависает до загрузки shell (опять же при подключенном токене). При этом без токена ПК нормально стартует. Вживую это выглядит следующим образом: компьютер кажется зависшим сразу после старта, пока токен торчит в разъёме. Вынимаешь его – загрузка внезапно продолжается. Подключаешь – снова висит. Явная проблема в UEFI, и о причинах можно только гадать.

Ситуация, когда невозможно открыть интерфейс USB_IO. Возможно, связана только с интерфейсом для работы со смарт-картами – USB CCID. Некий драйвер AMI уже открыл USB_IO c параметром EFI_OPEN_PROTOCOL_BY_DRIVER. Драйвер имеет протокол с GUID:

#define EFI_AMI_USB_CCID_PROTOCOL_GUID	 { 0x5FDEE00D, 0xDA40, 0x405A, { 0xB9, 0x2E, 0xCF, 0x4A, 0x80, 0xEA, 0x8F, 0x76} }
 // Workaround. Попытаться открыть протокол с флагом EFI_OPEN_PROTOCOL_BY_DRIVER, если ошибка, то открыть с флагом EFI_OPEN_PROTOCOL_GET_PROTOCOL.
 //
 // Open USB I/O Protocol
 //
 Status = gBS->OpenProtocol (
 ControllerHandle,
 &gEfiUsbIoProtocolGuid,
 (VOID **) &UsbIo,
 This->DriverBindingHandle,
 ControllerHandle,
 EFI_OPEN_PROTOCOL_BY_DRIVER
 );

 if (EFI_ACCESS_DENIED == Status)
 {		// AMI BIOS workaround (BindingStop will not be invoked)
	 Status = gBS->OpenProtocol(
		 ControllerHandle,
		 &gEfiUsbIoProtocolGuid,
		 (VOID **)&UsbIo,
		 This->DriverBindingHandle,
		 ControllerHandle,
		 EFI_OPEN_PROTOCOL_GET_PROTOCOL
	 );
 }

Однако при этом не будет вызван BindingStop(), т.е. событие извлечения устройства не отслеживается, и драйвер будет пытаться пользоваться invalid handle. Такое наблюдалось с ПК HP Compaq Elite 8300 SFF и с некоторыми другими. Это или своеобразная защита вендора от нежелательных драйверов, или обычный баг разработки.

:/>  Как запустить биос на Виндовс 10

Или другая интересная особенность. В одном из UEFI BIOS, где токен не обнаруживался, USB_IO позволял зачитать дескрипторы устройства, но на следующий UsbBulkTransfer() возвращалось EFI_INVALID_PARAMETER. Причем, такое происходило только с некоторыми типами токенов, с абсолютно теми же параметрами другие работали отлично.

Вообще, в протоколе EFI_USB_IO_PROTOCOL интересно реализован метод UsbBulkTransfer(). Он предназначен для гарантированной доставки пакета за неограниченное время, или за время, указанное в параметре Timeout. Но был проведен эксперимент с MassStorage устройством: при копировании большого файла на флешку она извлекалась.

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

Сложный характер систем

Платы Acer, Asus, AsRock и Gigabyte в большинстве случаев пишутся без лишних сложностей. Особняком стоят Intel, HP и серверное железо. HP мало того, что не даёт записать в себя программно, ещё и ругается на любую попытку модификации прошивки (у

по поиску и отключению проверки целостности). Intel более-менее записывался до 87-го чипсета, потом стал глух к просьбам открыть врата региона BIOS.

С Intel’ом первое время было забавно. Импорт модулей в прошивку выполнялся средствами утилиты UEFITool, и мы наткнулись на интересный баг: если вставить модули ffs в конец тома DXE, после всех freeform, то собранный образ «кирпичил» плату. Выходом было добавлять модули после любого родного DXE драйвера.

С серверным железом проще и сложнее одновременно. С одной стороны, на серверах всегда существуют дополнительные способы обновлять и модифицировать BIOS’ы, с другой – объем кастомизации в этих самых BIOS’ах зашкаливает, благо на сервера не скупятся и ставят достаточно вместительные микросхемы flash-памяти, зачастую еще и резервируя их.

При установке на сервера всегда неплохо иметь возможность удаленного обновления BIOS через IPMI. Правда, для этого по-хорошему нужна лицензия, само собой платная. Если её не оказывается в нужный момент, вполне возможно угодить в забавную ситуацию, подобную той, которую мы получили, внедряя модули в BIOS сервера Supermicro.

После внедрения модулей загрузка зависала намертво из-за блокирования одним из модулей безопасности (не учли своенравность серверных BIOS’ов, с кем не бывает!). При отсутствии возможности принудительно откатить BIOS через IPMI, рука сама потянулась к программатору, но вот незадача – стандартная SOIC-8 клипса оказалась маловатой для SOIC-16 микросхемы!

Ну и ладно, ведь в теории серверная плата имеет возможность резервного восстановления с подключенного носителя, подхватывая SUPER.ROM образ в корне. Но этот механизм не запускается, так как по мнению системы все ОК, все работает, следовательно, и откат BIOS’а не нужен! Что делать?!..

С Lenovo вышло ещё интереснее. На полученных от вендора свитчах, под крышкой корпуса была найдена управляющая плата с двумя «микрухами» под прошивку, с SSD под операционку и с жестко зафиксированной батарейкой. BIOS оказался крепким орешком, ни в какую не хотел кушать модифицированный образ, поддаваясь только программатору.

В одной из попыток что-то записать, в свитч вставили флешку с консольной убунтой (графику терминал не выдавал) и вполне благополучно загрузились. Сделав то, что требовалось, по старой памяти «выключили» систему командой halt -p. Свитч, по своей природе не приспособленный ни к какому выключению, кроме как по отсутствию питания, оказался не готов к такому и не хотел больше запускаться.

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

Исследование снятых с двух чипов дампов показало много интересного. В частности – огромное количество «Invalid» записей в NVRAM основной прошивки и несколько подобных в резервной. Ну и не встречавшуюся ранее мешанину данных в томе с DXE драйверами. О точной причине проблемы старта свитча оставалось только гадать.

Вообще, программная часть редко бывает лишена своих неожиданных нюансов. Многие попавшиеся нам платы до 87-го чипсета (разных производителей) имеют неприятную особенность выдавать бесконечный поток ошибок при вводе команды «dh -v» в консоли shell’a. При ручном вводе это не критично, но при сборе данных в файл это оканчивается досадным зависанием. В обоих случаях приходится перезагружать машину. Радует, что при этом файл с данными не распухает до необъятных размеров.

Очень своенравным показал себя BIOS ПК Kraftway с платой ASRock H81M-DGS. Так, на Ctrl Alt Del он реагирует зависанием, из которого его может вывести только Reset. Были проблемы и с пропуском в Shell’e загрузочного скрипта <startup.nsh> – доли секунды на выбор вместо пяти положенных по умолчанию. Возможно, эти проблемы вызваны модификацией фирменными модулями KSS, возможно, дело в неаккуратно «отвинченном» МЕ.

На плате Asus H97-PLUS в прошивке имеется следующая особенность – со временем переполняется BootOrder. Скорее всего, причина кроется в ошибках в коде. Хотя, может быть, производитель хотел сохранять все загрузочные устройства, когда-либо подключавшиеся в плате, но не рассчитал, что их может быть больше десятка за один день.

Так вот, когда BootOrder переполняется, происходит зависание системы в процессе загрузки. Для его очистки необходимо отключить все загрузочные устройства и включить систему. Прошивка очищает себя, и система загружается напрямую в оболочку BIOS Setup. Работоспособность сохраняется до следующего переполнения.

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

Оставьте комментарий

Adblock
detector