Microsoft UEFI第三方证书颁发机构（CA）要求正在更新，以要求UEFI映像包括内存缓解措施，此更新已在UEFI签名要求 - Microsoft技术社区中说明。
网络安全与基础结构安全机构最近发现，固件漏洞整体继续上升。 同时，部署的固件缓解技术不足以防止新式攻击，并且不会在供应商固件实现中统一应用缓解措施。
这些发现符合 Tianocore 社区、 安全研究社区和 UEFI 社区的行动呼吁。 生态系统需要基本缓解技术的基线，以提高 Windows 设备的平台安全性。
为了实现此目标，Microsoft引入了以下Microsoft第三方 UEFI CA 签名要求。
内存缓解签名要求
PE/COFF 元数据
提交的 PE 文件的节对齐必须与页面大小对齐。 这必须是 4 KB，或者是 2 的更大幂（例如 64 KB）。
节标志在任何给定部分中不得同时使用
IMAGE_SCN_MEM_WRITE和IMAGE_SCN_MEM_EXECUTE。
如果实施：PE/COFF DLL 认证
- DLL 特征必须包含
IMAGE_DLLCHARACTERISTICS_NX_COMPAT
由于无法静态检测到“无执行”（NX）符合性，因此设置 IMAGE_DLLCHARACTERISTICS_NX_COMPAT 的固件应遵循以下步骤，以确保固件映像可以在应用 NX 保护的情况下正常运行。
代码模块不得执行自我修改代码;这意味着应用程序的代码部分不得具有写入属性。 任何尝试更改内存范围内的值都会导致执行错误。
如果代码模块尝试将任何内部代码加载到内存中以供执行，或者如果它为外部加载程序提供支持，则必须适当地使用
EFI_MEMORY_ATTRIBUTE_PROTOCOL。 此可选协议允许调用方获取、设置和清除定义良好的内存范围的读取、写入和执行属性。- 加载到内存的内部代码必须保持
WRITE和EXECUTE排他性。 加载代码以允许执行后，还必须更改这些属性。 - 如果系统上可用，外部加载程序必须支持
EFI_MEMORY_ATTRIBUTE_PROTOCOL。 加载程序不得假定新分配的内存允许代码执行（即使是代码类型）。
- 加载到内存的内部代码必须保持
应用程序不得假定所有内存范围都有效;具体而言，第 0 页（通常位于物理地址 0 KB 到 4 KB）。
堆栈空间不能用于代码执行。
PE/COFF 图像验证工具可用于测试映像是否满足设置 DLL 特征位的元数据要求（静态图像 PE/COFF 要求）。
应用内存缓解要求
图像部分对齐使 UEFI/平台初始化（PI）固件环境能够保护包含页表属性的部分。 此外，固件组件应假定页表属性应用于固件映像以启用以下功能：
不执行（NX）内存保护机制 - 任何非代码段都将被标记为NX，代码段将被标记为只读（RO），以防止在代码段外执行代码并覆盖代码段。
页防护 - 可以在分配相应页面之前和之后添加保护页。 任何访问防护页的尝试都会导致页面错误（#PF）。
池防护 - 在分配的池占用的内存部分前后放置头防护页和尾卫页。 建议供应商对下溢（使用头防护页）和溢出（使用尾部防护页）进行供应商固件测试。
CPU 堆栈防护 - 防护页设置为“页表中不存在”，并放置在堆栈底部以检测堆栈溢出。
空指针保护 - 禁止访问第一个页（地址为零）。 尽管旧版 BIOS 实现将中断向量表（IVT）放在此位置，但 UEFI 固件应预计这个页面被标记为“不存在”，以便捕捉 null 指针引用。
文件对齐方式与分区对齐方式
MSVC 等链接器通常提供多种对齐选项。 例如，在 MSVC 中， /FILEALIGN 会影响二进制文件布局中的对齐方式，而二进制文件布局可能会对整体文件大小产生相对较大的影响。
/ALIGN 控制加载后各种分区在内存中的对齐方式。 本部分对齐方式（/ALIGN）对于这些更改非常重要。
后向兼容性
平台固件可以在尝试启用 IMAGE_DLLCHARACTERISTICS_NX_COMPAT 时保留向后兼容性，具体方法是在加载没有设置IMAGE_DLLCHARACTERISTICS_NX_COMPAT位的模块时，恢复 RWX 内存分配。 预计随着生态系统逐步接受这一变化，此策略将被逐渐取消。