Coreboot 4.17 Released

CoreBoot 4.17 project has been published, within 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.

Main changes:

• Fixed a vulnerability (CVE-2022-29264) that occurs in CoreBoot releases from 4.13 to 4.16 and allows, on systems with an AP (Application Processor), to execute code at the SMM (System Management Mode) level, which has a higher priority (Ring -2) than the hypervisor mode and zero protection ring, 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) и Lite Mk IV (N5030).
• Dropped support for Google Deltan and Deltaur motherboards.
• A new payload coreDOOM has been added to allow you to run a DOOM game from Coreboot. The project uses doomgeneric code ported to libpayload. Coreboot’s 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.
• SeaGRUB mode (GRUB2 over SeaBIOS) has been added, which allows GRUB2 to use the callbacks provided by SeaBIOS, for example, to access equipment that is not accessible from GRUB2 payload.
• Added protection against the SinkHole attack, which allows you to execute code 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.
• Allowed writing debug information to the CBMEMC console from SMI handlers when using DEBUG_SMI.
• Changed the system of CBMEM initialization handlers, instead of *_CBMEM_INIT_HOOK handlers tied to stages two handlers are proposed CBMEM_CREATION_HOOK (used in the initial stage that creates cbmem) and CBMEM_READY_HOOK (used in any stages where cbmem is already created).
• Added support for PSB (Platform Secure Boot), activated by the PSP (Platform Security Processor) to verify the integrity of the BIOS by digital signature.
• Added own implementation of debug data handler passed 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.
• i2c device detection has been implemented to make it easier to work with boards equipped with touchpads or touchscreens 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 time from user space to the cbmem “timestamp” table, which makes it possible to reflect events in cbmem at stages executed after CoreBoot.

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 the initialization of SoC Intel. The lack of FSP code makes it very difficult to create open firmware and hinders the progress of the Coreboot, U-Boot and LinuxBoot projects on Intel hardware. Previously, a similar initiative was successful and Intel opened the code for community-requested PSE (Programmable Services Engine) firmware.