The CoreBoot 4.17 project release has been published, which develops a free alternative to proprietary firmware and BIOS. The project's code is distributed under the GPLv2 license. 150 developers participated in creating the new version, preparing over 1300 changes.
Key Changes:
- A vulnerability (CVE-2022-29264) has been fixed, which affected CoreBoot releases from 4.13 to 4.16 and allowed code execution at the SMM (System Management Mode) level on systems with an AP (Application Processor), which is more privileged (Ring -2) than the hypervisor mode and the zero protection ring, having unrestricted access to all memory. The issue was caused by an incorrect SMI handler call in the smm_module_loader module.
- Support has been added for 12 motherboards, 5 of which are used on devices with Chrome OS or on servers Google. Among the unrelated to Google boards:
- 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), and Lite Mk IV (N5030).
- Support for the Google Deltan and Deltaur motherboards has been discontinued.
- A new payload coreDOOM has been added, which allows the game DOOM to run from Coreboot. The project uses the doomgeneric code, ported to libpayload. For output, the Coreboot linear framebuffer is used, and WAD files with game resources are loaded from CBFS.
- Payload components SeaBIOS 1.16.0 and iPXE 2022.1 have been updated.
- SeaGRUB mode (GRUB2 on top of SeaBIOS) has been added, allowing GRUB2 to use the callback calls provided by SeaBIOS, for example, to access hardware not accessible from the GRUB2 payload.
- Protection against the SinkHole attack has been added, allowing code execution at the SMM (System Management Mode) level.
- A built-in capability for generating static memory page tables from assembly files has been implemented, eliminating the need to call external utilities.
- Debugging information can be written to the CBMEMC console from SMI handlers when using DEBUG_SMI.
- The CBMEM initialization handler system has been changed; instead of stage-bound *_CBMEM_INIT_HOOK handlers, two CBMEM_CREATION_HOOK (used at the initial stage which creates cbmem) and CBMEM_READY_HOOK (used at any stage where cbmem has already been created) handlers are proposed.
- Support for PSB (Platform Secure Boot), activated by the PSP (Platform Security Processor) processor for verifying the integrity of the BIOS via digital signature, has been added.
- A custom implementation of the debug data handler has been added, which transmits data from FSP (FSP Debug Handler).
- Manufacturer-specific TIS functions (TPM Interface Specification) have been added for reading and writing directly from the TPM (Trusted Platform Module) registers — tis_vendor_read() and tis_vendor_write().
- Support for intercepting null pointer dereferences through debug registers has been added.
- The ability to identify i2c devices has been implemented, simplifying work with boards equipped with touchpads or touchscreens from various manufacturers.
- The ability to save timestamp data in a format suitable for generating FlameGraph charts, clearly demonstrating how much time is spent at different stages of startup, has been added.
- The cbmem utility has been updated with an option to include a 'timestamp' in the cbmem table from user space, allowing events occurring after CoreBoot stages to be reflected in cbmem.
Additionally, the OSFF (Open-Source Firmware Foundation) has published an open letter to Intel, proposing to make firmware support packages (FSP, Firmware Support Package) more modular and start publishing documentation related to Intel SoC initialization. The lack of FSP code significantly complicates the creation of open firmware and hinders the advancement of Coreboot, U-Boot, and LinuxBoot projects on Intel hardware. A similar initiative previously succeeded, where Intel released the requested community firmware code for the PSE (Programmable Services Engine) block.
Source: opennet.ru
