前言
很久以前在做等保的时候，我注意到三级等保中有一个控制项叫做可信验证，其对应的控制点为：
可信验证要求：可基于可信根对计算设备的系统引导程序、系统程序、重要配置参数和通信引导程序等进行可信验证，并在应用程序的关键执行环节进行动态可信验证，在检测到其可信性受到破坏后进行报警，并将验证结果形成审计记录送至安全管理中心。
当时前辈说这一条不做测评默认不通过，因为等保2.0中有很多项是“现在做不到但是需要先立在那里”。直到最近我看到刚发布的基础架构安全弹性技术指南草案（固件安全篇），我才开始重新审视固件安全这个过去被忽视的安全点，并且出于记录写下了本篇blog。
本文是关于2022年5月17日发布的《基础架构安全弹性技术指南草案（固件安全篇）alpha 预览版》的阅读笔记与延申思考。具体会思考到哪去我也不知道，毕竟我对于底层固件等内容也并没有太多了解。
注：本文引用的内容如无额外标记皆出自《基础架构安全弹性技术指南草案（固件安全篇）alpha 预览版》。
什么是固件
本文档将探讨平台固件（platform firmware）安全，并且可能会可互换地简称为固件
（firmware）。固件（firmware）这一概念拥有多种定义，在手机/嵌入式/物联网设备的上下文中，大多时候固件指所有软件（操作系统和应用程序），手机/相机/游戏机的固件更新通常是整个基础软件的更新，这比通用计算设备上单独更新应用程序会具备更高的风险，在这些设备上的固件更新通常包括校验和以及多重引导程序能力以避免使得设备异常不可用（例如固件损毁“变砖”），在这个背景下，嵌入式领域的固件大多时候由 Linux 或者 BSD 变种构成的独立的操作系统。与之相反，本文档讨论固件的范围限于 UEFI、ACPI 、PCI OptionROM、CSME 等平台固件，值得注意的是，任何复杂到同时拥有操作系统和应用程序的移动/嵌入式/物联网设备很可能不仅仅拥有一种固件，而是拥有若干种平台固件（platform firmware）用于板载的微控制器或者处理器，例如，一台物联网网关设备可能由一个运行 Linux 系统主处理器、一个用于安全验证的处理器和若干微控制器组成。