Opublikowano wydanie projektu CoreBoot 4.17, w ramach którego rozwijana jest darmowa alternatywa dla proprietarnych firmware'ów i BIOS. Kod projektu jest udostępniany na licencji GPLv2. W tworzeniu nowej wersji wzięło udział 150 deweloperów, którzy przygotowali ponad 1300 zmian.
Główne zmiany:
- Usunięto lukę (CVE-2022-29264), występującą w wersjach CoreBoot od 4.13 do 4.16, która umożliwiała na systemach z AP (Application Processor) wykonanie kodu w trybie SMM (System Management Mode), o wyższym priorytecie (Ring -2) niż tryb hypervisora i zero-ring, i mającym nieograniczony dostęp do całej pamięci. Problem wynikał z niepoprawnego wywołania handlera SMI w module smm_module_loader.
- Dodano wsparcie dla 12 płyt głównych, z czego 5 jest używanych w urządzeniach z Chrome OS lub na serwerach Google. Wśród płyt niezwiązanych z Google znajdują się:
- Clevo L140MU / L141MU / L142MU
- Dell Precision T1650
- Stacja robocza HP Z220 CMT
- Star Labs LabTop Mk III (i7-8550u), LabTop Mk IV (i3-10110U, i7-10710U), Lite Mk III (N5000) oraz Lite Mk IV (N5030).
- Zaprzestano wsparcia dla płyt głównych Google Deltan i Deltaur.
- Dodano nowy payload coreDOOM, umożliwiający uruchomienie gry DOOM z Coreboot. W projekcie wykorzystano kod doomgeneric, przeniesiony na libpayload. Do wyświetlania używany jest liniowy framebuffer Coreboot, a pliki WAD z zasobami gry są ładowane z CBFS.
- Zaktualizowano komponenty payload SeaBIOS 1.16.0 oraz iPXE 2022.1.
- Dodano tryb SeaGRUB (GRUB2 na SeaBIOS), umożliwiający w GRUB2 korzystanie z callbacków SeaBIOS, na przykład do uzyskiwania dostępu do sprzętu, do którego z payload GRUB2 nie ma dostępu.
- Dodano ochronę przed atakiem SinkHole, umożliwiającą wykonanie kodu w trybie SMM (System Management Mode).
- Wdrożono wbudowaną możliwość generowania statycznych tabel stron pamięci z plików asm, bez potrzeby wywoływania zewnętrznych narzędzi.
- Zezwolono na zapis informacji debugowych do konsoli CBMEMC z handlerów SMI przy użyciu DEBUG_SMI.
- Zmieniono system handlerów inicjalizacji CBMEM, zamiast związanych z etapami handlerów *_CBMEM_INIT_HOOK zaproponowano dwa handlery CBMEM_CREATION_HOOK (używane na wczesnym etapie, tworzącym cbmem) oraz CBMEM_READY_HOOK (używane na jakichkolwiek etapach, na których cbmem już istnieje).
- Dodano wsparcie dla PSB (Platform Secure Boot), aktywowanego przez procesor PSP (Platform Security Processor) w celu weryfikacji integralności BIOS poprzez cyfrowy podpis.
- Dodano własną implementację handlera danych debugowych przesyłanych z FSP (FSP Debug Handler).
- Dodano specyficzne dla producentów funkcje TIS (TPM Interface Specification) do odczytu i zapisu bezpośrednio z rejestrów TPM (Trusted Platform Module) — tis_vendor_read() i tis_vendor_write().
- Dodano wsparcie dla przechwytywania dereferencji wskaźników zerowych za pośrednictwem rejestrów debugowania.
- Wprowadzono wykrywanie urządzeń i2c, co ułatwia pracę z płytami wyposażonymi w touchpady lub ekrany dotykowe różnych producentów.
- Dodano możliwość zapisywania danych o czasie w formacie odpowiednim do generowania wykresów FlameGraph, które wyraźnie pokazują, ile czasu jest spędzane na różnych etapach uruchamiania.
- Do narzędzia cbmem dodano opcję dodawania do tabeli cbmem znacznika czasowego z przestrzeni użytkownika, co umożliwia odzwierciedlenie w cbmem zdarzeń na etapach, które są realizowane po CoreBoot.
Dodatkowo należy odnotować publikację fundacji OSFF (Open-Source Firmware Foundation) otwartego listu do firmy Intel, w którym propozycja dotyczy uczynienia zestawów wsparcia dla firmware (FSP, Firmware Support Package) bardziej modułowymi oraz rozpoczęcia publikowania dokumentacji związanej z inicjalizacją SoC Intel. Brak kodu FSP znacząco utrudnia tworzenie otwartych firmware i przeszkadza w promocji projektów Coreboot, U-Boot i LinuxBoot na sprzęcie Intela. Wcześniej podobna inicjatywa zakończyła się sukcesem, a firma Intel udostępniła kod firmware bloku PSE (Programmable Services Engine) na prośbę społeczności.
Źródło: opennet.ru
