The release of the CoreBoot 4.17 project has been published, within the framework of which a free alternative to proprietary firmware and BIOS is being developed. The project code is distributed under the GPLv2 license. 150 developers took part in the creation of the new version, who prepared more than 1300 changes.
Major changes:
- A vulnerability (CVE-2022-29264) that appeared in CoreBoot releases 4.13 to 4.16 has been fixed and allows code to be executed on systems with AP (Application Processor) at the SMM (System Management Mode) level, which has a higher priority (Ring -2) than the hypervisor mode and a zero ring of protection, and having unlimited access to all memory. The problem is caused by an incorrect call to the SMI handler in the smm_module_loader module.
- Added support for 12 motherboards, 5 of which are used on Chrome OS devices or Google servers. Among non-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).
- Dropped support for Google Deltan and Deltaur motherboards.
- Added a new payload coreDOOM that allows you to run a DOOM game from Coreboot. The project uses doomgeneric code, ported to libpayload. The Coreboot linear framebuffer is used for output, and WAD files with game resources are loaded from CBFS.
- Updated payload components SeaBIOS 1.16.0 and iPXE 2022.1.
- Added SeaGRUB mode (GRUB2 over SeaBIOS), which allows GRUB2 to use the callback calls provided by SeaBIOS, for example, to access equipment that is not accessible from the GRUB2 payload.
- Added protection against the SinkHole attack, which allows code to be executed at the SMM (System Management Mode) level.
- The built-in ability to generate static memory page tables from assembler files has been implemented, without the need to call third-party utilities.
- Allow writing debugging information to the CBMEMC console from SMI handlers when using DEBUG_SMI.
- The system of CBMEM initialization handlers has been changed; instead of the *_CBMEM_INIT_HOOK handlers tied to the stages, two handlers are proposed: CBMEM_CREATION_HOOK (used at the initial stage that creates cbmem) and CBMEM_READY_HOOK (used at any stages at which cbmem has already been created).
- Added support for PSB (Platform Secure Boot), activated by the PSP (Platform Security Processor) processor to verify the integrity of the BIOS using a digital signature.
- Added our own implementation of a handler for debugging data transferred from FSP (FSP Debug Handler).
- Added vendor-specific TIS (TPM Interface Specification) functions for reading and writing directly from TPM (Trusted Platform Module) registers - tis_vendor_read() and tis_vendor_write().
- Added support for intercepting null pointer dereferences via debug registers.
- Implemented i2c device detection, making it easier to work with boards equipped with touchpads or touch screens from different manufacturers.
- Added the ability to save time data in a format suitable for generating FlameGraph graphs that clearly demonstrate how much time is spent at different stages of the launch.
- An option has been added to the cbmem utility to add a βtimestampβ of time from user space to the cbmem table, which makes it possible to reflect events in stages performed after CoreBoot in cbmem.
Additionally, we can note the publication by the OSFF (Open-Source Firmware Foundation) of an open letter to Intel, which proposes 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 prevents the advancement of Coreboot, U-Boot and LinuxBoot projects on Intel hardware. Previously, a similar initiative was successful and Intel opened the code for the PSE (Programmable Services Engine) block firmware requested by the community.
Source: opennet.ru