New UEFI CA memory mitigation requirements for signing

This post has been republished via RSS; it originally appeared at: Hardware Dev Center articles.

Microsoft, in conjuncture with partners in the PC ecosystem, has developed a set of capabilities and new operating environment conditions for UEFI based systems.  This environment will leverage common, architecturally defined mitigations to improve the device security and boot process.  For software running in this environment there are new requirements that must be adhered to.  For the continuity of our joint customers, it is critical we move the UEFI third-party ecosystem forward together. 

Starting November 30th, 2022 the memory mitigations described below will be required for all applications to be signed by the Microsoft third-party Unified Extensible Firmware Interface (UEFI) Certificate Authority (CA).  

Requirements 

PE-COFF metadata  

1. Section Alignment of the submitted PE file must be aligned with page size.  This must be 4kb, or a larger power of 2 (ex 64kb) 
2. Section Flags must not combine IMAGE_SCN_MEM_WRITE and IMAGE_SCN_MEM_EXECUTE for any given section. 

If-implemented: PE-COFF DLL Attestation 

• DLL Characteristics must include IMAGE_DLLCHARACTERISTICS_NX_COMPAT 

If a developer is building full support for NX firmware, then they must follow the steps below to fully support and test. Then, since these app characteristics can not be detected statically, setting IMAGE_DLLCHARACTERISTICS_NX_COMPAT attests that the submitted application has successfully implemented and tested the following behavior: 

1. The application must not run self-modifying code; meaning that the code sections of the application may not have the write attribute.  Any attempt to change values within the memory range will cause an execution fault.  
2. If the application attempts to load any internal code into memory for execution, or if it provides support for an external loader, then it must use the EFI_MEMORY_ATTRIBUTE_PROTOCOL appropriately.  This optional protocol allows the caller to get, set, and clear the read, write, and execute attributes of a well-defined memory range.  
   1. Loading internal code into memory must maintain WRITE and EXECUTE exclusivity. It must also change the attributes after loading the code to allow execution.    
   2. External loaders must support the protocol if available on the system. The loader must not assume newly allocated memory allows code execution (even of code types).   
3. The application must not assume all memory ranges are valid; specifically, page 0 (PA 0 – 4kb). 
4. Stack space cannot be used for code execution 

To assist with quickly testing the metadata requirements and setting the DLL characteristic bit, please use this provided validation tool. 

The following links and FAQ are here to support the ecosystem and developers with learning about and implementing these new requirements. Thank you to all for continued collaboration. For any questions around signing, please contact uefisign@microsoft.com.  

LINKS: 

New Reqs doc: UEFI CA Memory Mitigation Requirements for Signing - Windows drivers | Microsoft Docs 

EFI_MEMORY_ATTRIBUTE_PROTOCOL definition: 3519 – Add Memory Protection proposal - UEFI_MEMORY_ATTRIBUTE protocol (tianocore.org) 

Section Alignment: https://docs.microsoft.com/windows/win32/debug/pe-format#optional-header-windows-specific-fields-image-only 

Section Flags: https://docs.microsoft.com/windows/win32/debug/pe-format#section-flags 

DLL Characteristics: https://docs.microsoft.com//windows/win32/debug/pe-format#dll-characteristics 

Binary test tool documentation: edk2-pytool-extensions/using_image_validation_tool.md at master · tianocore/edk2-pytool-extensions (github.com) 

Binary test tool code: edk2-pytool-extensions/image_validation.py at master · tianocore/edk2-pytool-extensions (github.com) 

Open source QEMU based UEFI test environment: mu_tiano_platforms/building.md at release/202202 · microsoft/mu_tiano_platforms (github.com) 

FAQ: 

Q – Does this mean binary images sizes will grow? 

A – In most cases, no.  Most binary files can have different file and section alignment values.  For example, the MSVC linker has the /FILEALIGN and /ALIGN flags.  File align controls the binary file layout while align controls how the various sections will be aligned in memory once loaded.  As mentioned, section alignment is what is critical for these features.   

/FILEALIGN (Align sections in files) | Microsoft Docs 

/ALIGN (Section Alignment) | Microsoft Docs 

Q - Given how long it takes for 3rd party binaries to be deployed and old versions "phased out", how does Microsoft expect OEMs to move forward with these enforcements.   

A - It is expected that an OEM will use the presence of the IMAGE_DLLCHARACTERISTICS_NX_COMPAT in 3rd party binaries as a trigger to support compatibility.  When the flag is not set the OEM, if it wants to continue to support the older binary, would restore the memory environment and page attributes.   Our expectation is this compatibility will go away over time as new versions become prevalent in the ecosystem.  This behavior will be required to support all versions of Windows boot prior to 22621.1.