Securing the EDK II Image Loader

Abstract

The Unified Extensible Firmware Interface (UEFI) is a standardised interface between the firmware and the operating system used in all x86-based platforms over the past ten years, which continues to spread to other architectures such as ARM and RISC-V. The UEFI incorporates a modular design based on images containing a driver or an application in a Common Object File Format (COFF) either as a Portable Executable (PE) or as a Terse Executable (TE). The de-facto standard generic UEFI services implementation, including the image loading functionality, is TianoCore EDK II. Its track of security issues shows numerous design and implementation flaws some of which are yet to be addressed. In this paper we outline both the requirements for a secure UEFI Image Loader and the issues of the existing implementation. As an alternative we propose a formally verified Image Loader supporting both PE and TE images with fine-grained hardening enabling a seamless integration with EDK II and subsequently with the other firmwares.

UEFI virtual machine firmware hardening through snapshots and attack surface reduction

“…• the use of modern development tools for mission-critical software such as formal verification (PE loader [28]), fuzzing (parser of firmware configuration files), and static analysis (Svace [31]); • the support for booting both Windows (from 7 to 10) and Linux operating systems, with the ability to bypass the GRUB boot loader for the latter, on x86 and x86 64; • utility code to create firmware configuration files on all major desktop operating systems. The proposed set of tools of the Amaranth project allows one to substantially reduce the following threats:…”

“…Obviously, all modern development tools for mission-critical software should always be used during the development of such a product. We performed formal verification of the PE loader with the AstraVer toolset [28], fuzzed critical parsing code parts, such as firmware configuration handling code, and ran static analysis with Svace [31]. To further reduce the risks of bugs residing in the codebase without our knowledge we created a hardened operating environment with the support for memory protection, stack canaries, stack overflow guards, and automatic variable initialisation.…”

“…When the platform starts, the compliance of the OS state with the configuration file, the structure of which is shown in Listing 2, is checked by a special library firmware module, which has been designed taking into account critical security requirements. Despite the importance of these requirements, they are often neglected [28]. When applied to the configuration file parser, the security requirements are quite simple: 1) When one passes any structure to a function, one should always pass not only a pointer to this structure, but also its size.…”