UEFI, bootloaders, and Rust

There was a talk about UEFI programming in Rust at MadRust, the Madrid Rust Meetup:



Rust en primavera: UEFI y GTK

Thursday, Apr 4, 2019, 7:15 PM

Calle de Pradillo, 42
Calle de Pradillo, 42 Madrid, ES

36 Rustaceans Attending

Llegó la primavera, y con ella otra ración de programación de sistemas con Rust. Alberto Ruiz [1] es un Engineering Manager en Red Hat [2] en el equipo de Bootloader. En su charla se sumergirá en UEFI [3], la especificación de firmware estándar en la mayoría de sistemas Intel para consumidores; y mostrará cómo compilar un Hello World básico (y quiz…

Check out this Meetup →

UEFI 2.8 released

The UEFI Forum has released the v2.8 specification for UEFI. March not only had the 2.8 release, but a 2.7b release. The last release, 2.7, was in August 2017.



Below are list of changes from 2.7b and 2.8, from the Revision History section of the spec.

[The Mantis Number is the entry in the bug database which has all the details on the change, only UEFI Forum members have access to that data,  all that is shown in the public spec is the Mantis Number and Bug Title. Non-members will need to use this Description String to try and find the updated section in the spec and look for recent Tianocore implmentation code checkins, or maybe wait for Nikolaj to issue a series of Tweets…]

Revision Mantis Number / Description Date
2.8 1832 Extend SERIAL_IO with DeviceTypeGuid
2.8 1834 UEFI REST EX Protocol
2.8 1853 Adding support for a REST style formset
2.8 1858 New Device Path for bootable NVDIMM namespaces
2.8 1861 New EFI_MEMORY_RANGE_CAPSULE Descriptor
2.8 1866 GetInfo() of Adapter Information Protocol should have a provision for IHV to return no data
2.8 1872 Peripheral-attached Memory
2.8 1876 Remove the EBC support requirement
2.8 1879 Clarification of REST (EX) protocol
2.8 1908 Update of uncommitted data in the FOROM_OPEN callback
2.8 1919 Memory Cryptography Attribute
2.8 1920 Redfish Discover Protocol
2.8 1921 HTTPS hostname validation
2.8 1924 Update to EFI_REST_EX_PROTOCOL.AsyncSendReceive
2.8 1925 Clarify requirement of REST related protocols
2.8 1926 New UEFI Spec Revision –> 2.8
2.8 1935 UEFI JSON Capsule Support
2.8 1936 ResetSystem – support ResetData for all status scenarios.
2.8 1937 Behavior of default values
2.8 1941 New EFI REST JSON Structure Protocol
2.8 1942 Adding dependency expression capability into FMP type capsules
2.8 1947 Keyword strings of Configuration Keyword Handler Protocol Enhancements
2.8 1953 Add document version# conventions
2.8 1954 set (*Attributes) when GetVariable() returns EFI_BUFFER_TOO_SMALL and Attributes is non-NULL
2.8 1956 Platform to honor ActionRequest for Action changing
2.8 1966 Add new capsule processing error codes
2.8 1974 Add new CCIX PER Log Error Section to appendix
2.8 1996 Firmware Processing of the Capsule Identified by EFI_JSON_CAPSULE_ID_GUID
2.7B 1773 Clarify The EFI System Table entry for capsule image
2.7B 1801 ExtractConfig() format may change when called multiple times
2.7B 1835 Misleading / unclear statement about EFI-bootability of UDF media
2.7B 1838 RGB/BGR Contradiction in 2.7 GOP
2.7B 1841 BluetoothLE ECR – support autoreconnect
2.7B 1842 BluetoothLE ECR – Add missing ConnectionCompleteCallback
2.7B 1843 HTTP Example Code Update
2.7B 1844 Replace obsoleted RFC number with new number for TCP
2.7B 1845 Clarification on AIP types “Network boot” and “SAN MAC Address”
2.7B 1846 EFI_LOAD_FILE2 requirement
2.7B 1865 Adding clarification in EFI_NOT_READY for ReadKeyStrokeEx()
2.7B 1869 Clarify FMP buffer too small behavior
2.7B 1874 Add RFC3021 to reference in uefi.org
2.7B 1875 Clarify platform specific elements in chapter 2.6.2
2.7B 1878 Errata – Make DHCP server optional for HTTP boot
2.7B 1880 Arm binding EL2 register state clarification
2.7B 1890 EfiMemoryMappedIO Usage Clarification
2.7B 1897 Clarification on mapping of UEFI memory attributes to ARM memory types and paging attributes
2.7B 1899 Errata: Clarify EFI_INVALID_PARAMETER for FMP->GetImageInfo()
2.7B 1901 GPT Protective MBR description
2.7B 1902 CapsuleImageSize Clarification
2.7B 1903 Root Directory File Name
2.7B 1906 ACPI Table Pointer Installation
2.7B 1908 Update of uncommitted data in the FOROM_OPEN callback
2.7B 1923 Syntax error in EFI iSCSI Initiator Name Protocol
2.7B 1957 Request to add status code EFI_DEVICE_ERROR for ExtractConfig
2.7B 1964 Print disclaimer for all future UEFI specs
2.7B 1987 incorrect VLAN_CONFIG_SET function definition

Tianocore Security Advisories: 10 new entries for March

There are 10 new UEFI/Tianocore Security Advisories, 32-40. I don’t see 10 new CVEs, though…

32. DNS Packet Size Check: Buffer overflow in network stack for EDK II may allow unprivileged user to potentially enable escalation of privilege and/or denial of service via network.


33. Opal BlockSid Setting Disabled after S3: Improper configuration in system firmware for EDK II may allow unauthenticated user to potentially enable escalation of privilege, information disclosure and/or denial of service via local access.


34. PartitionDxe and Udf Buffer Overflow: Buffer overflow in system firmware for EDK II may allow unauthenticated user to potentially enable escalation of privilege and/or denial of service via network access.



35. Stack Overflow on Corrupted BMP: Stack overflow in corrupted bmp for EDK II may allow unprivileged user to potentially enable denial of service or elevation of privilege via local access.


36. Buffer Overflow in BlockIo service for RAM disk: Buffer overflow in BlockIo service for EDK II may allow an unauthenticated user to potentially enable escalation of privilege, information disclosure and/or denial of service via network access.


37. XHCI stack local stack overflow: Stack overflow in XHCI for EDK II may allow an unauthenticated user to potentially enable denial of service via local access.


38. SW SMI Confused Deputy SmramSaveState.c: Insufficient memory write check in SMM service for EDK II may allow an authenticated user to potentially enable escalation of privilege, information disclosure and/or denial of service via local access.


39. Unlimited FV Recursion: Stack overflow in DxeCore for EDK II may allow an unauthenticated user to potentially enable escalation of privilege, information disclosure and/or denial of service via local access.


40. AuthVariable Timestamp Zeroing on APPEND_WRITE: Logic issue in variable service module for EDK II/UDK2018/UDK2017/UDK2015 may allow an authenticated user to potentially enable escalation of privilege, information disclosure and/or denial of service via local access.



Exploiting signed bootloaders to circumvent UEFI Secure Boot

The author of: Super-UEFIinSecureBoot-Disk < https://firmwaresecurity.com/2019/02/27/super-uefiinsecureboot-disk-is-a-bootable-image-with-grub2-bootloader-designed-to-be-used-as-a-base-for-recovery-usb-flash-drives/ > has a new post on Habr.com (in Russian) on UEFI Secure Boot security.

Excerpt of Google Translation: […]In this article we proved the existence of not enough reliable bootloaders signed by Microsoft key, which allows booting untrusted code in Secure Boot mode. Using signed Kaspersky Rescue Disk files, we achieved a silent boot of any untrusted .efi files with Secure Boot enabled, without the need to add a certificate to UEFI db or shim MOK. These files can be used both for good deeds (for booting from USB flash drives) and for evil ones (for installing bootkits without computer owner consent).[…]



GRUB2 security changes in Fedora

[…]Include Grub’s “verify,” “cryptodisk,” “luks” and <others here> modules in grubx64.efi of the ‘grub2-efi-x64’ package.  Users utilising secure boot functionality on the UEFI platform cannot insert modules that aren’t in grubx64.efi. Paradoxically, this means that security-conscious users cannot use grub’s verify module, or employ (near) full disk encryption using cryptodisk and luks. The security benefits of signature verification would reach more users if Fedora automated it by incorporating the process into grub2-mkconfig. For the long-term, to grant flexibility with grub2 modules on secure boot instances, it may be advisable to sign the .mod files in the ‘grub2-efi-x64-modules’ package, modify grub2-mkconfig (or -install) to copy the necessary modules into the EFI partition when required by the user’s configuration and then allow inserting of signed modules in secure boot instances.[…]




bcdedit-revert-uefi-gpt-boot-order: Powershell script to modify the UEFI/GPT boot order

This powershell script modifies the UEFI/GPT boot order by finding the first non-Windows entry and moving it to the top of the order. When using UEFI+GPT, the Windows installation (since Windows 7?) creates its own boot device entry (“Windows Boot Manager”, a.k.a. “{bootmgr}”) in the UEFI/GPT boot order list and, obnoxiously, takes the liberty of moving said entry to the top of the list. Under most circumstances, this is fine, and probably desirable. However for systems used for repeated deployment testing, or systems which you want a different bootloader to take priority (such as dual-boot systems, or computer lab systems that can be remotely re-imaged), this is a show stopper. So I needed a way to do this programmatically. This script makes use of the arcane and undocumented {fwbootmgr} identifier implemented by bcdedit to find the first non-Windows boot device entry in the UEFI/GPT boot order list and move it to the top of the list.


EfiPy: Python Library for accessing UEFI BIOS internal function by protocol

I just noticed this project, and it’s been around for years, and I’ve been using UEFI and Python for years, sigh. 😦 It appears the developer is Max Wu of Phoenix. There is a blog, in addition to the tool. The blog has also been around for a long time, last post was last month, on UEFI topic not scoped to EfiPy.

EfiPy is a Python Module on UEFI shell which can access UEFI BIOS kernel interface:
– System Table
– Runtime Services
– Boot Services

pAnalyzer package –
Tracing UEFI protocol calling flow
Output protocol flow to screen or file with XML format

CorePy (assembly package) –
Simple Assembly code in Python environment.

EfiPy Shell package-
Simple uefi shell program coded with EfiPy library to prove EfiPy workable

EfiPy leverage these open source packages – ctypes, CorePy.




UEFI Utility DisplayBMP Updated to Support More Formats and Scrolling

This post details recent updates to a simple UEFI shell utility for displaying BMP images that I first released in 2015 and subsequently updated in 2017, and again this year. Source code for the previous versions is available on Github at UEFI-Utilities-2016 and UEFI-Utilities-2018 respectfully.[…]