Veröffentlichung von Coreboot 4.17

Die Version 4.17 des CoreBoot-Projekts wurde veröffentlicht, das eine freie Alternative zu proprietären Firmware und BIOS entwickelt. Der Code des Projekts wird unter der GPLv2-Lizenz veröffentlicht. An der Erstellung der neuen Version haben 150 Entwickler mit über 1300 Änderungen mitgewirkt.

Wesentliche Änderungen:

• Eine Sicherheitsanfälligkeit (CVE-2022-29264) wurde behoben, die in den CoreBoot-Versionen von 4.13 bis 4.16 auftritt und es auf Systemen mit AP (Application Processor) ermöglicht, Code im SMM (System Management Mode) auszuführen, welcher eine höhere Priorität (Ring -2) als der Hypervisor und das Null-Ring-Schutz bietet und uneingeschränkten Zugriff auf den gesamten Speicher hat. Das Problem wurde durch einen fehlerhaften 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 oder auf Servern Google eingesetzt. Unter den nicht mit Google verbundenen Platinen sind:
  • 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 der 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 Spielressourcen 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 ermöglicht, die von SeaBIOS bereitgestellten Callback-Aufrufe in GRUB2 zu verwenden, zum Beispiel um auf Hardware zuzugreifen, auf die das Payload GRUB2 nicht zugreifen kann.
• Ein Schutz gegen die SinkHole-Attacke wurde implementiert, der es ermöglicht, Code im SMM (System Management Mode) auszuführen.
• Die integrierte Möglichkeit zur Generierung statischer Seiten-Tabellen aus Assembler-Dateien wurde implementiert, ohne dass externe Utilities aufgerufen werden müssen.
• Das Schreiben von Debug-Informationen in die CBMEMC-Konsole aus SMI-Handlern bei Verwendung von DEBUG_SMI wurde ermöglicht.
• Das System der Initialisierungs-Handler für CBMEM wurde geändert. Statt an Phasen gebundener Handler 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).
• Unterstützung für PSB (Platform Secure Boot) wurde hinzugefügt, die durch den PSP (Platform Security Processor) aktiviert wird, um die Integrität des BIOS durch digitale Signaturen zu überprüfen.
• Eine eigene Implementierung des Debug-Daten-Handlers, die aus dem FSP (FSP Debug Handler) übergeben wird, wurde hinzugefügt.
• Herstellerbezogene TIS-Funktionen (TPM Interface Specification) wurden hinzugefügt, um direkt aus den Registern des TPM (Trusted Platform Module) zu lesen und zu schreiben — tis_vendor_read() und tis_vendor_write().
• Unterstützung für das Abfangen von Dereferenzierungen von Nullzeigern über Debug-Register hinzugefügt.
• Implementierung zur Identifizierung von i2c-Geräten, die die Arbeit mit Boards erleichtert, die mit Touchpads oder Touchscreens unterschiedlicher Hersteller ausgestattet sind.
• Die Möglichkeit wurde hinzugefügt, Zeitdaten im Format zu speichern, das für die Erstellung von FlameGraph-Diagrammen geeignet ist, die anschaulich zeigen, wie viel Zeit in den verschiedenen Phasen des Starts aufgewendet wird.
• Die cbmem-Anwendung wurde um die Option erweitert, einen 'timestamp' von Benutzerraumzeit in die cbmem-Tabelle einzufügen, was es ermöglicht, Ereignisse in cbmem für Phasen darzustellen, die nach CoreBoot ausgeführt werden.

Zusätzlich möchten wir die Veröffentlichung eines offenen Briefs der OSFF (Open-Source Firmware Foundation) an Intel hervorheben. In diesem wird vorgeschlagen, die Firmware Support Packages (FSP) modularer zu gestalten und damit zu beginnen, Dokumentationen zur Initialisierung von Intel SoCs zu veröffentlichen. Das Fehlen des FSP-Codes erschwert erheblich die Erstellung offener Firmwares und behindert die Weiterentwicklung von Projekten wie Coreboot, U-Boot und LinuxBoot auf Intel-Hardware. Eine ähnliche Initiative war zuvor erfolgreich, als Intel den Code der von der Community angeforderten Firmware für die Programmable Services Engine (PSE) öffnete.

Quelle: opennet.ru