UEFI memory mitigations
The Microsoft 3rd Party UEFI Certificate Authority (CA) requirements are being updated to mandate that UEFI images include memory mitigations - these changes will be reflected in UEFI Signing Requirements - Microsoft Tech Community.
The Cybersecurity & Infrastructure Security Agency recently found that firmware vulnerabilities, as a whole, continue to rise. Meanwhile, firmware mitigation techniques being deployed are insufficient to prevent modern attacks and mitigations aren't being applied uniformly across vendor firmware implementations.
These findings are consistent with calls to action from the Tianocore community, the security research community, and the UEFI community. A baseline of fundamental mitigation techniques are needed across the ecosystem to improve the platform security of Windows devices.
To realize this goal, Microsoft is introducing the following Microsoft 3rd Party UEFI CA signing requirements.
Memory mitigation signing requirements
PE/COFF metadata
Section Alignment of the submitted PE file must be aligned with page size. This must be 4 KB, or a larger power of 2 (for example, 64 KB).
Section Flags must not combine
IMAGE_SCN_MEM_WRITEandIMAGE_SCN_MEM_EXECUTEfor any given section.
If-implemented: PE/COFF DLL attestation
- DLL Characteristics must include
IMAGE_DLLCHARACTERISTICS_NX_COMPAT
Since No Execute (NX) compliance can't be detected statically, firmware that sets IMAGE_DLLCHARACTERISTICS_NX_COMPAT
should follow these steps to ensure that the firmware image can operate correctly with NX protections applied.
The code module must not execute self-modifying code; meaning that the code sections of the application must not have the write attribute. Any attempt to change values within the memory range will cause an execution fault.
If the code module 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_PROTOCOLappropriately. This optional protocol allows the caller to get, set, and clear the read, write, and execute attributes of a well-defined memory range.- Internal code loaded into memory must maintain
WRITEandEXECUTEexclusivity. The attributes must also be changed after loading the code to allow execution. - External loaders must support
EFI_MEMORY_ATTRIBUTE_PROTOCOLif available on the system. The loader must not assume newly allocated memory allows code execution (even of code types).
- Internal code loaded into memory must maintain
The application must not assume all memory ranges are valid; specifically, page 0 (typically at physical address 0 to 4 KB).
Stack space can't be used for code execution.
A PE/COFF Image Validation Tool is available to test that an image meets the metadata requirements (static image PE/COFF requirements) for setting the DLL Characteristic bit.
Application of memory mitigation requirements
Image section alignment enables the UEFI/Platform Initialization (PI) firmware environment to protect the section with page table attributes. In addition, firmware components should assume page table attributes will be applied to a firmware image to enable the following features:
No Execute (NX) memory protection - Any non-code sections will be marked as NX and code sections will be marked read-only (RO) to prevent execution outside code sections and overwriting of code sections.
Page guards - A guard page may be added before and after the corresponding page allocated. Any attempt to access the guard page will result in a page fault (#PF).
Pool guards - A head guard page and a tail guard page will be placed before and after the portion of memory, which the allocated pool occupies. It's recommended that vendor firmware tests for both underflow (using a head guard page) and overflow (using a tail guard page).
CPU stack guard - A guard page is set to Not Present in the page table and placed onto the bottom of the stack to detect stack overflow.
Null pointer protection - No accesses to the first page (at address zero). While legacy BIOS implementations placed the Interrupt Vector Table (IVT) at this location, UEFI firmware should expect that this page is marked as Not Present to catch null pointer dereferences.
File alignment vs section alignment
Linkers such as MSVC, typically offer
several alignment options. For example, in MSVC, /FILEALIGN affects alignment within the binary file layout that
can have a relatively larger impact on the overall file size. /ALIGN controls how various sections will be aligned
in memory once loaded. This section alignment (/ALIGN) is what is important for these changes.
Backward compatibility
A platform firmware can preserve backward compatibility while attempting to enable IMAGE_DLLCHARACTERISTICS_NX_COMPAT
by restoring RWX memory allocations when a module is loaded that doesn't have the IMAGE_DLLCHARACTERISTICS_NX_COMPAT
bit set. It's expected that this policy will be removed over time ecosystem adopts this change.
Related resources
/FILEALIGN (align sections in files)
A tour beyond BIOS - Memory protection in UEFI BIOS
DHS CISA strategy to fix vulnerabilities below the OS among worst offenders
Project Mu: Memory Protections Feature
Safeguarding UEFI ecosystem: Firmware supply chain is hard(coded)
Feedback
Submit and view feedback for