Versione Coreboot 4.17

È stato pubblicato il rilascio del progetto CoreBoot 4.17, nell'ambito del quale è in fase di sviluppo un'alternativa gratuita al firmware e al BIOS proprietari. Il codice del progetto è distribuito sotto la licenza GPLv2. Alla creazione della nuova versione hanno preso parte 150 sviluppatori che hanno preparato più di 1300 modifiche.

Principali modifiche:

  • È stata corretta una vulnerabilità (CVE-2022-29264) comparsa nelle versioni CoreBoot da 4.13 a 4.16 che consente l'esecuzione del codice su sistemi con AP (Application Processor) a livello SMM (System Management Mode), che ha una priorità più alta ( Ring -2) rispetto alla modalità hypervisor e un anello di protezione zero e accesso illimitato a tutta la memoria. Il problema è causato da una chiamata errata al gestore SMI nel modulo smm_module_loader.
  • Aggiunto supporto per 12 schede madri, 5 delle quali utilizzate su dispositivi con Chrome OS o su server Google. Tra le tariffe non Google:
    • Clevo L140MU/L141MU/L142MU
    • Dell Precision T1650
    • Stazione di lavoro HP Z220 CMT
    • Star Labs LabTop Mk III (i7-8550u), LabTop Mk IV (i3-10110U, i7-10710U), Lite Mk III (N5000) e Lite Mk IV (N5030).
  • Il supporto per le schede madri Google Deltan e Deltaur è stato interrotto.
  • Aggiunto un nuovo payload coreDOOM, che ti consente di avviare il gioco DOOM da Coreboot. Il progetto utilizza codice doomgeneric, portato su libpayload. Per l'output viene utilizzato il framebuffer lineare Coreboot e i file WAD con le risorse di gioco vengono caricati da CBFS.
  • Componenti del payload aggiornati SeaBIOS 1.16.0 e iPXE 2022.1.
  • Aggiunta la modalità SeaGRUB (GRUB2 su SeaBIOS), che consente a GRUB2 di utilizzare le chiamate di callback fornite da SeaBIOS, ad esempio, per accedere ad apparecchiature non accessibili dal payload GRUB2.
  • Aggiunta protezione contro l'attacco SinkHole, che consente l'esecuzione del codice a livello SMM (System Management Mode).
  • Implementata la capacità integrata di generare tabelle statiche di pagine di memoria da file assembly, senza la necessità di chiamare utilità di terze parti.
  • Consenti la scrittura di informazioni di debug sulla console CBMEMC dai gestori SMI quando si utilizza DEBUG_SMI.
  • È stato modificato il sistema dei gestori di inizializzazione CBMEM; al posto dei gestori *_CBMEM_INIT_HOOK legati agli stage, vengono proposti due gestori: CBMEM_CREATION_HOOK (utilizzato nella fase iniziale che crea cbmem) e CBMEM_READY_HOOK (utilizzato in tutte le fasi in cui cbmem è già stato creato).
  • Aggiunto il supporto per PSB (Platform Secure Boot), attivato dal processore PSP (Platform Security Processor) per verificare l'integrità del BIOS tramite firma digitale.
  • Aggiunta la nostra implementazione di un gestore per il debug dei dati trasferiti da FSP (FSP Debug Handler).
  • Aggiunte funzioni TIS (TPM Interface SPECIFIC) specifiche del fornitore per leggere e scrivere direttamente dai registri TPM (Trusted Platform Module): tis_vendor_read() e tis_vendor_write().
  • Aggiunto supporto per intercettare dereferenziazioni di puntatori nulli tramite registri di debug.
  • Implementato il rilevamento dei dispositivi i2c, semplificando il lavoro con schede dotate di touchpad o touch screen di diversi produttori.
  • Aggiunta la possibilità di salvare i dati temporali in un formato adatto alla generazione di grafici FlameGraph, che dimostrano chiaramente quanto tempo viene impiegato nelle diverse fasi del lancio.
  • È stata aggiunta un'opzione all'utilità cbmem per aggiungere un "timestamp" temporale dallo spazio utente alla tabella cbmem, che rende possibile riflettere gli eventi nelle fasi eseguite dopo CoreBoot in cbmem.

Si segnala inoltre la pubblicazione da parte dell'OSFF (Open-Source Firmware Foundation) di una lettera aperta indirizzata a Intel, in cui si propone di rendere più modulari i pacchetti di supporto firmware (FSP, Firmware Support Package) e di iniziare a pubblicare la documentazione relativa all'inizializzazione del SoC Intel. . La mancanza di codice FSP complica notevolmente la creazione di firmware aperto e impedisce l'avanzamento dei progetti Coreboot, U-Boot e LinuxBoot sull'hardware Intel. In precedenza, un'iniziativa simile aveva avuto successo e Intel aveva aperto il codice per il firmware del blocco PSE (Programmable Services Engine) richiesto dalla community.

Fonte: opennet.ru

Aggiungi un commento