Vladimir Serbinenko, one of the three mayor GRUB2 bootloader maintainers, made more than five thousand changes in the code base and put up for discussion the possibility of using the Rust language for writing code in Grub2. He also presented the first results of experiments by adding support for Rust in Grub2 and creating necessary strands. Changes have been prepared for GRUB, allowing the use of separated libraries (“.SO”, et_dyn) for modules, instead of binding at the level of object files (“.O”, et_rel).
The initiative is currently positioned as a separate experiment that will not affect the development of GRUB2. The optimal use of Rust in GRUB mentioned spelling of modules for new file systems. It is also likely that rewriting code related to work with disk sections and GPT will be done in Rust.
It is assumed that the use of Rust will help the project reduce the likelihood of some types of errors, especially in the code containing many larger ones with complex Procedures parsing. In February, as a result of the audit of the code base, 72 security problems in GRUB were identified, 21 of which were recognized as dangerous vulnerabilities suitable for bypassing the UEFI Secure Boot Verified load mechanism. 20 out of 21 vulnerabilities are caused by errors when working with memory that led to buffer overflow or memory access after its release.
Additionally, the release of project GNU Boot 0.1 RC6 included corrections for vulnerabilities (patches for GRUB2 continue to be spread without a separate release). The GNU Boot project develops a replacement for UEFI and BIOS proprietary firmware, based on Coreboot, with stricter requirements for inclusion of binary components. GNU Boot is positioned as “Coreboot-Libre”, aiming to provide a firmware free of blobs and non-free components, similar to how the Linux-Libre project is developed for the Linux kernel. Separate similar projects include Libreboot and Canoeboot.