Coreboot. Практическое знакомство со свободной альтернативой BIOS

Николай, Минск, Беларусь

LVEE 2015

In modern Open Source world we need an open alternative to the proprietary product called BIOS. This alternative exists and is called coreboot. Coreboot is not fully equal to BIOS, it's only does initialization of RAM, execution of binary vendor blobs and starting some payload. The report main task is to cover how to start using it.

Введение

Для построения полностью свободного стека ПО необходимо иметь свободную альтернативу проприетарным прошивкам (firmware): классическому BIOS, либо UEFI в более новых системах. Такая альтернатива есть, и она называется coreboot.

Практические причины для использования CoreBoot¹ могут быть:

Нужда в свободной альтернативе UEFI;
Создание единого командно-интерфейсного слоя в уровне “прошивки” для кластерных решений на различных системах и архитектурах;
Ускорить загрузку системы до ОС (до ~3с)
Разместить всю ОС (GNU/Linux, FreeBSD или другую) во флеш памяти, позволив работать в режиме восстановления либо в полноценном режиме без использования жесткого диска;
Общеобразовательные :)
Предотвращение угрозы полумифического BadBIOS²³;

Процесс загрузки Coreboot

В процессе загрузки, устройство с coreboot проходит через следующие стадии:

ROM stage – инициализация памяти и начальная инициализация чипсета; помимо общей схемы действий эта часть по понятным причинам очень специфична для конкретного оборудования, и здесь в обязательном порядке присутствует выполнение некоторых частей бинарной прошивки, которая определена производителем как обязательная для инициализации RAM, CPU или других системных устройств;
RAM stage – нумерация устройств, назначение ресурсов, создание таблицы ACPI, SMM handler;
Payload – выполнение некой полезной нагрузки, которая в свою очередь может быть неким приложением либо загрузить операционную систему.

Coreboot не является полной заменой BIOS, т.к. не содержит никакой активной части по выполнению “полезных действий”: эта часть вынесена в отдельный модуль, называемый “payload” (полезная нагрузка). Достоинство такого разделения – возможность менять payload. Например, автором в качестве payload использован SeaBIOS, но есть и альтернативы, такие как “GRUB2”, “OpenBIOS”. Можно “выполнить” в качестве payload ядро Linux или FreeBSD, а можно создать собственный: например, очень нужный в реальной практике payload, который пишет “hello world” и завершается:

#include “libpayload.h”

 int main(void)

 {

     printf(“Hello, world from CoreBoot! :)\n”);

     return 0;

 }

Сборка этого шедевра функциональности может быть выполнена следующим способом:

 $ lpgcc -o hello.elf hello.c

После чего, данный Payload необходимо добавить в Ваш бинарный файл Coreboot.rom и можно перейти на этап загрузки его в ПЗУ.

Подготовка coreboot к прошивке

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

В частности, подготовительные шаги для установки coreboot на основе личного опыта автора по перепрошивке ThinkPad x201⁴ выглядели следующим образом:

тщательное изучение документации по разборке ноутбука, чтобы отыскать чипы памяти BIOS и CMOS;
чтение datasheet’ов на ROM и выяснение специфики его программирования;
покупка (либо сборка) программатора и разъёмов (SOIC-8P) для ISP программирования;
извлечение videorom.bin из оригинального проприетарного BIOS, которую можно получить из ОЗУ в процессе работы системы;
создание резервной копии firmware с помощью программного или аппаратного программатора (эксперименты с подобными материями быстро излечивают от неоправданного оптимизма);
клонирование coreboot и его зависимостей из git, выполнение ‘make menuconfig’ и ‘make’, с последующими n часами сборки с удовлетворением всех зависимостей;
программирование в ПЗУ результирующего бинарного файла;
многочасовое тестирование компьютера с новой микропрограммой, с использованием нагрузочных тестов и проверкой всего оборудования.

Саму запись микропрограммы в постоянную память можно выполнить из Linux её штатными средствами – “flashrom”, либо, если этот этап завершился неудачей – аппаратным программатором. В случае с Thinkpad x201 для программирования MX25L6445E (8MB Serial Flash) подходят программаторы:

BusPirate v4;
minipro TL866C;
Raspberry PI;
любой другой, который умеет программировать через SPI.

Из-за того, что программная перепрошивка оказалась заблокирована вендором (а способ разблокировки, применяемый для обновления фирменной прошивки, на данный момент неизвестен), для LENOVO Thinkpad x201 пришлось воспользоваться аппаратным программатором minipro TL866. При работе из GNU/Linux команда перепрошивки должна выглядеть примерно следующим образом:



./minipro -i -p “MX25L6445E @SOP8” -w {Patch_for_your_coreboot}build/coreboot.rom

Советы по внутрисхемному программированию:

Важно следить за уровнем питания микросхемы на плате. Если питания не достаточно, есть смысл воспользоваться внешним блоком питания. Обычный стандартный блок ATX для таких задач вполне подходит (необходимо +3.3V);
Для получения корректных результатов считывания и записи “Земля” (GND) программатора, корпуса ноутбука и блока питания должны быть соединены;
Перед записью будет не лишним попробовать прочитать содержимое микросхемы N раз и проверить контрольные суммы – SHA или MD5. Если они не совпадают, проблема наверняка кроется в двух предыдущих пунктах.

Работоспособность после прошивки

В результате экспериментов с ThinkPad x201 были выявлены следующие мелкие баги (которые, возможно, на момент чтения этой статьи уже будут исправлены):

ограничение “на перегрев CPU” теперь отсутствует, что требует добавить ещё один скрипт проверки на перегрев, либо понизить немного частоту CPU до стабильной, что бы этот перегрев и не возникал;
каждые 10 минут возникает “засыпание” экрана, вне зависимости от установок xset (Исправляется xset -dpms off);
при подключенном втором дисплее перестает регулироваться яркость подсветки основного дисплея используя горячие клавиши;
понадобилось переписать скрипт регулировавший частоту процессора из-за новых значений шага для частоты CPU;
проигрывание звука на колонках отключается программно, то есть при включенных наушниках можно включить воспроизведение на встроенных динамиках ноутбука;

Однако список работающего функционала оказался внушительным:

3G GPRS modem;
4G+4G RAM;
функциональные клавиши ThinkPad (фонарик, громкость);
расширения VT-x процессора;
аппаратная поддержка AES в CPU;
WIFI;
Ethernet;
Все порты ноутбука (USB, DP, HDMI, DSUB), а также док-станция;
Устройство считывания отпечатков пальцев;
Управление питанием устройства, контроль за состоянием батареи.

Время загрузки микропрограммы, инициализации всего аппаратного обеспечения и передача управления начальному загрузчику ОС (GRUB2) сократилось с ~50 с до ~4 с, и при том большую часть из этого времени SeaBIOS ожидает нажатия F12 для выбора устройства загрузки. Хотя ускорение загрузки не являлось целью данной работы, нельзя не отметить, что логотип coreboot соответствует его значению:

Конечно, данное обстоятельно не может не радовать.

Отладка

Подготовленный payload можно протестировать в эмуляторе QEMU-KVM перед запуском, чтобы удостовериться, что всё работает как требуется. В самом же устройстве можно использовать традиционный для этих задач индикатор POST-кодов, отображающий значения, отправленные в порт 80h, последовательный порт – либо PC-speaker как средства диагностики состояния и процесса загрузки.