È stata pubblicata la versione del progetto CoreBoot 4.17, nell'ambito della quale si sviluppa un'alternativa open source ai firmware e BIOS proprietari. Il codice del progetto è distribuito sotto licenza GPLv2. Nella creazione di questa nuova versione hanno partecipato 150 sviluppatori, che hanno preparato più di 1300 modifiche.
Variazioni principali:
- È stata corretta una vulnerabilità (CVE-2022-29264) presente nelle versioni di CoreBoot da 4.13 a 4.16, che permette, su sistemi con AP (Application Processor), di eseguire codice a livello SMM (System Management Mode), un livello di priorità superiore (Ring -2) rispetto alla modalità hypervisor e al livello zero di protezione, con accesso illimitato a tutta la memoria. Il problema è stato causato da una chiamata errata al gestore SMI nel modulo smm_module_loader.
- Aggiunta la supporto per 12 schede madri, 5 delle quali sono utilizzate su dispositivi con Chrome OS o su server Google. Tra le schede non collegate a Google:
- Clevo L140MU / L141MU / L142MU
- Dell Precision T1650
- HP Z220 CMT Workstation
- Star Labs LabTop Mk III (i7-8550u), LabTop Mk IV (i3-10110U, i7-10710U), Lite Mk III (N5000) e Lite Mk IV (N5030).
- Interrotta la supporto per le schede madri Google Deltan e Deltaur.
- Aggiunto un nuovo payload coreDOOM, che consente di avviare il gioco DOOM da Coreboot. Nel progetto è stato utilizzato il codice doomgeneric, portato su libpayload. Per l'output viene utilizzato il framebuffer lineare di Coreboot, mentre i file WAD con le risorse di gioco vengono caricati da CBFS.
- Aggiornati i componenti payload SeaBIOS 1.16.0 e iPXE 2022.1.
- Aggiunto il supporto per SeaGRUB (GRUB2 sopra SeaBIOS), che consente l'uso delle chiamate di callback fornite da SeaBIOS in GRUB2, ad esempio per accedere all'hardware, al quale non c'è accesso dal payload GRUB2.
- Aggiunta la protezione contro l'attacco SinkHole, che consente di eseguire codice a livello SMM (System Management Mode).
- Implementata la possibilità integrata di generare tabelle statiche delle pagine di memoria dai file assembly, senza necessità di chiamare strumenti di terze parti.
- Permessa la scrittura di informazioni di debug nella console CBMEMC dai gestori SMI con DEBUG_SMI attivato.
- Cambiato il sistema dei gestori di inizializzazione CBMEM, invece dei gestori *_CBMEM_INIT_HOOK legati alle fasi, sono stati proposti due gestori CBMEM_CREATION_HOOK (utilizzato nelle fasi iniziali, per creare cbmem) e CBMEM_READY_HOOK (utilizzato in qualsiasi fase in cui cbmem è già stato creato).
- Aggiunto il supporto per PSB (Platform Secure Boot), attivato dal processore PSP (Platform Security Processor) per la verifica dell'integrità del BIOS tramite firma digitale.
- Aggiunta un'implementazione personalizzata del gestore di dati di debug, trasmessi da FSP (FSP Debug Handler).
- Aggiunte funzionalità specifiche per produttori TIS (TPM Interface Specification) per leggere e scrivere direttamente dai registri TPM (Trusted Platform Module) — tis_vendor_read() e tis_vendor_write().
- Aggiunta la supporto per l'intercettazione della dereferenziazione di puntatori nulli tramite registri di debug.
- Realizzata la rilevazione dei dispositivi i2c, semplificando il lavoro con schede dotate di touchpad o schermi touch di diversi produttori.
- Aggiunta la possibilità di salvare i dati temporali in un formato adatto per la generazione di grafici FlameGraph, che mostrano chiaramente quanto tempo viene speso in diverse fasi di avvio.
- Nell'utilità cbmem è stata aggiunta un'opzione per aggiungere nella tabella cbmem un "timestamp" dallo spazio utente, consentendo di riflettere in cbmem eventi nelle fasi eseguite dopo CoreBoot.
Inoltre, si può notare la pubblicazione da parte della OSFF (Open-Source Firmware Foundation) di una lettera aperta a Intel, in cui si propone di rendere i pacchetti di supporto del firmware (FSP, Firmware Support Package) più modulari e iniziare a pubblicare la documentazione relativa all'inizializzazione dei SoC Intel. L'assenza di codice FSP rende notevolmente più difficile la creazione di firmware open-source e ostacola l'avanzamento dei progetti Coreboot, U-Boot e LinuxBoot su hardware Intel. In precedenza, un'iniziativa simile ha avuto successo e Intel ha rilasciato il codice richiesto dalla comunità per i firmware del blocco PSE (Programmable Services Engine).
Fonte: opennet.ru
