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_WRITE and IMAGE_SCN_MEM_EXECUTE for 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_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.
Internal code loaded into memory must maintain WRITE and EXECUTE exclusivity. The attributes must also be
changed after loading the code to allow execution.
External loaders must support EFI_MEMORY_ATTRIBUTE_PROTOCOL if available on the system. The loader must not
assume newly allocated memory allows code execution (even of code types).
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.
Learn about advanced firmware and security features of Microsoft Surface devices, Surface UEFI, Project Mu, configuring Virtualization-based Security and Memory Integrity in Windows, and Firmware Attack Surface Reduction.
As a Microsoft cybersecurity architect, you translate a cybersecurity strategy into capabilities that protect the assets, business, and operations of an organization.