Erscheinungsdatum von Coreboot 4.17

Die Veröffentlichung von CoreBoot 4.17 bringt eine freie Alternative zu proprietären Firmware- und BIOS-Systemen. Der Code des Projekts wird unter der GPLv2-Lizenz verbreitet. An der Erstellung der neuen Version haben 150 Entwickler mit mehr als 1300 Änderungen mitgewirkt.

Hauptänderungen:

• Eine Sicherheitsanfälligkeit (CVE-2022-29264) wurde behoben, die in Versionen von CoreBoot von 4.13 bis 4.16 auftritt und es ermöglicht, auf Systemen mit AP (Application Processor) Code im SMM (System Management Mode) auszuführen, der einen höheren Prioritätsgrad (Ring -2) hat als der Hypervisor-Modus und der Null-Schutzring, und der uneingeschränkten Zugriff auf den gesamten Speicher hat. Das Problem wird durch einen falschen Aufruf des SMI-Handlers im Modul smm_module_loader verursacht.
• Die Unterstützung für 12 Mainboards wurde hinzugefügt, von denen 5 in Geräten mit Chrome OS verwendet werden oder in Servern Google verwendet werden. Zu den nicht mit Google verbundenen Boards gehören:
  • 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) und Lite Mk IV (N5030).
• Die Unterstützung für die Mainboards Google Deltan und Deltaur wurde eingestellt.
• Ein neuer Payload coreDOOM wurde hinzugefügt, der es ermöglicht, das Spiel DOOM aus Coreboot zu starten. Im Projekt wurde der Code doomgeneric verwendet, der auf libpayload portiert wurde. Für die Ausgabe wird der lineare Framebuffer von Coreboot verwendet, und die WAD-Dateien mit den Spieledaten werden aus CBFS geladen.
• Die Payload-Komponenten SeaBIOS 1.16.0 und iPXE 2022.1 wurden aktualisiert.
• Der SeaGRUB-Modus (GRUB2 über SeaBIOS) wurde hinzugefügt, der es erlaubt, die von SeaBIOS bereitgestellten Callback-Aufrufe in GRUB2 zu nutzen, beispielsweise um auf Hardware zuzugreifen, auf die GRUB2-Payload keinen Zugriff hat.
• Ein Schutz gegen die SinkHole-Attacke wurde hinzugefügt, der es ermöglicht, Code im SMM (System Management Mode) auszuführen.
• Die eingebaute Möglichkeit zur Generierung statischer Seiten-Tabellen aus Assembler-Dateien wurde implementiert, ohne dass externe Utilities aufgerufen werden müssen.
• Die Ausgabe von Debugging-Informationen in die CBMEMC-Konsole aus SMI-Handlern bei Verwendung von DEBUG_SMI wurde erlaubt.
• Das System von CBMEM-Initialisierungs-Handlern wurde geändert. Anstelle von an Phasen gebundenen Handlern wurden zwei Handler vorgeschlagen: CBMEM_CREATION_HOOK (wird in der Anfangsphase verwendet, die cbmem erstellt) und CBMEM_READY_HOOK (wird in allen Phasen verwendet, in denen cbmem bereits erstellt wurde).
• Die Unterstützung für PSB (Platform Secure Boot) wurde hinzugefügt, die durch den PSP-Prozessor (Platform Security Processor) aktiviert wird, um die Integrität des BIOS durch digitale Signaturen zu verifizieren.
• Eine eigene Implementierung des Debug-Datenhandlers, die aus FSP (FSP Debug Handler) übergeben wird, wurde hinzugefügt.
• Hersteller-spezifische TIS-Funktionen (TPM Interface Specification) zum Lesen und Schreiben direkt aus den Register TPM (Trusted Platform Module) — tis_vendor_read() und tis_vendor_write() wurden hinzugefügt.
• Unterstützung für die Abfangung von Dereferenzierungen nuller Zeiger über Debug-Register wurde hinzugefügt.
• Die Erkennung von i2c-Geräten wurde implementiert, um die Arbeit mit Boards, die mit Touchpads oder Touchscreens verschiedener Hersteller ausgestattet sind, zu erleichtern.
• Die Möglichkeit, Zeitdaten in einem Format zu speichern, das sich für die Erstellung von FlameGraph-Diagrammen eignet und anschaulich darstellt, wie viel Zeit in verschiedenen Phasen des Bootvorgangs aufgewendet wird, wurde hinzugefügt.
• In das cbmem-Tool wurde eine Option zum Hinzufügen eines „Timestamp“ aus dem Benutzerspeicher in die cbmem-Tabelle eingefügt, was es ermöglicht, Ereignisse in cbmem in den Phasen darzustellen, die nach CoreBoot ausgeführt werden.

Zusätzlich kann die Veröffentlichung eines offenen Briefes durch die OSFF (Open-Source Firmware Foundation) an Intel erwähnt werden, in dem vorgeschlagen wird, die Firmware-Support-Pakete (FSP, Firmware Support Package) modularer zu gestalten und zu beginnen, Dokumentationen zur Initialisierung von Intel SoCs zu veröffentlichen. Das Fehlen des FSP-Codes erschwert erheblich die Erstellung offener Firmware und behindert die Fortschritte der Coreboot-, U-Boot- und LinuxBoot-Projekte auf Intel-Hardware. Eine ähnliche Initiative war zuvor erfolgreich, und Intel hat den Code der angeforderten Firmware für das PSE (Programmable Services Engine) veröffentlicht.

Quelle: opennet.ru