Coreboot 4.17-Version

Die Veröffentlichung des CoreBoot 4.17-Projekts wurde veröffentlicht, in dessen Rahmen eine kostenlose Alternative zu proprietärer Firmware und BIOS entwickelt wird. Der Projektcode wird unter der GPLv2-Lizenz vertrieben. An der Erstellung der neuen Version waren 150 Entwickler beteiligt, die mehr als 1300 Änderungen vorbereitet haben.

Wichtigste Änderungen:

  • Eine Schwachstelle (CVE-2022-29264), die in den CoreBoot-Versionen 4.13 bis 4.16 auftrat, wurde behoben und ermöglicht die Ausführung von Code auf Systemen mit AP (Application Processor) auf der SMM-Ebene (System Management Mode), die eine höhere Priorität hat ( Ring -2) als der Hypervisor-Modus und ein Null-Ring-Schutz und unbegrenzten Zugriff auf den gesamten Speicher. Das Problem wird durch einen falschen Aufruf des SMI-Handlers im Modul smm_module_loader verursacht.
  • Unterstützung für 12 Motherboards hinzugefügt, von denen 5 auf Geräten mit Chrome OS oder auf Google-Servern verwendet werden. Zu den Nicht-Google-Gebühren 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 Google Deltan- und Deltaur-Motherboards wurde eingestellt.
  • Es wurde eine neue Nutzlast coreDOOM hinzugefügt, mit der Sie das DOOM-Spiel über Coreboot starten können. Das Projekt verwendet doomgenerischen Code, portiert auf libpayload. Für die Ausgabe wird der lineare Coreboot-Framebuffer verwendet und WAD-Dateien mit Spielressourcen werden von CBFS geladen.
  • Aktualisierte Nutzlastkomponenten SeaBIOS 1.16.0 und iPXE 2022.1.
  • SeaGRUB-Modus hinzugefügt (GRUB2 über SeaBIOS), der es GRUB2 ermöglicht, die von SeaBIOS bereitgestellten Rückrufaufrufe zu verwenden, um beispielsweise auf Geräte zuzugreifen, auf die über die GRUB2-Nutzlast nicht zugegriffen werden kann.
  • Zusätzlicher Schutz gegen den SinkHole-Angriff, der die Ausführung von Code auf der SMM-Ebene (System Management Mode) ermöglicht.
  • Es wurde eine integrierte Funktion zum Generieren statischer Tabellen mit Speicherseiten aus Assemblydateien implementiert, ohne dass Dienstprogramme von Drittanbietern aufgerufen werden müssen.
  • Erlauben Sie das Schreiben von Debugging-Informationen von SMI-Handlern in die CBMEMC-Konsole, wenn Sie DEBUG_SMI verwenden.
  • Das System der CBMEM-Initialisierungshandler wurde geändert; anstelle der *_CBMEM_INIT_HOOK-Handler, die an die Stufen gebunden sind, werden 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 vorhanden war). erstellt).
  • Unterstützung für PSB (Platform Secure Boot) hinzugefügt, das vom PSP-Prozessor (Platform Security Processor) aktiviert wird, um die Integrität des BIOS mithilfe einer digitalen Signatur zu überprüfen.
  • Wir haben unsere eigene Implementierung eines Handlers zum Debuggen von Daten hinzugefügt, die von FSP übertragen wurden (FSP Debug Handler).
  • Herstellerspezifische TIS-Funktionen (TPM Interface Specification) zum Lesen und Schreiben direkt aus TPM-Registern (Trusted Platform Module) hinzugefügt – tis_vendor_read() und tis_vendor_write().
  • Unterstützung für das Abfangen von Nullzeiger-Dereferenzierungen über Debug-Register hinzugefügt.
  • Die i2c-Geräteerkennung wurde implementiert, um die Arbeit mit Boards zu erleichtern, die mit Touchpads oder Touchscreens verschiedener Hersteller ausgestattet sind.
  • Es wurde die Möglichkeit hinzugefügt, Zeitdaten in einem Format zu speichern, das zum Generieren von FlameGraph-Diagrammen geeignet ist, die deutlich zeigen, wie viel Zeit in den verschiedenen Phasen des Starts aufgewendet wird.
  • Dem cbmem-Dienstprogramm wurde eine Option hinzugefügt, um der cbmem-Tabelle einen „Zeitstempel“ der Zeit aus dem Benutzerbereich hinzuzufügen, was es ermöglicht, Ereignisse in nach CoreBoot durchgeführten Phasen in cbmem widerzuspiegeln.

Darüber hinaus können wir die Veröffentlichung eines offenen Briefes an Intel durch die OSFF (Open-Source Firmware Foundation) zur Kenntnis nehmen, in dem vorgeschlagen wird, Firmware-Unterstützungspakete (FSP, Firmware Support Package) modularer zu gestalten und mit der Veröffentlichung von Dokumentation zur Initialisierung des Intel SoC zu beginnen . Das Fehlen von FSP-Code erschwert die Erstellung offener Firmware erheblich und verhindert die Weiterentwicklung von Coreboot-, U-Boot- und LinuxBoot-Projekten auf Intel-Hardware. Zuvor war eine ähnliche Initiative erfolgreich und Intel öffnete den von der Community angeforderten Code für die PSE-Block-Firmware (Programmable Services Engine).

Source: opennet.ru

Kommentar hinzufügen