Intel Alder Lake固件整体方案泄漏分析

根据github泄漏仓库的时间戳信息，2022年9月30日，一名未确认身份的用户上传了Intel Alder Lake平台的固件整体方案，其中包含参考实现，OEM实现，IBV方案以及相关文档，大小为4.8GB。

2022年10月8日，此次泄漏引起了媒体tom’sHardware的关注和报道，随后泄漏仓库被删除，但安全研究者依然可以时间机器获得泄漏内容。

固件供应商 Insyde

OEM制造商 Lenovo

支持平台 Intel Alder Lake

主机固件方案 UEFI

Insyde作为固件整体方案商会持续开发和集成各平台的支持，此次泄漏的内容是Insyde方案的删减版本，仅支持Alder Lake，泄漏的内容有几个比较有趣的内容：

    * 由Insyde提供的完整工具链，用于简化OEM厂商的开箱以及BIOS镜像调整工作

    * Insyde的定制框架，其封装了兼容EDK2的接口，让ODM/OEM厂商更容易集成平台组件比如Intel FSP

    * Intel参考实现以及OEM的实现，这次泄露事件中的OEM主角是Lenovo联想

    * Binary blobs：值得注意的是，其中除了各种设备（蓝牙BLE，WiFi，以太网等）所需要的binary blobs外，也包含了三种不同的用于安全特性的ACM：BiosGuard，BootGuard以及TXT

另外，一个值得关注的点是BootGuard开箱所用的密钥堆也在泄漏内容中：

x86启动的前半部的ACM是由Intel签名，后半部则是OEM厂商控制:

让我们祈祷Lenovo并没有将它们用于生产环境，请证明我们是错的！

UEFI原本对高于操作系统权限的SMM（系内容涉及一些和状态相关的内容，由于Dmitry的抄送，Harbian-QA的maintainer参与了一些讨论，值得注意的是，在讨论中，Vegard Nossum提出了一种方法，即对结构及成员进行hash来收集数据访问情况，并且在不到24小时内发布他为此开发的GCC plugin的PoC原型。这个方法其实和2020年 Harbian-QA发布的Clang/LLVM以instrumentation的实现内容很相似，但只收集访问结构体及其成员名的hash，Vegard Nossum似乎是为了这个触发并发错误开发的，和 Harbian-QA设计目标有所不同，后面会继续讨论。

很遗憾，不能或者非常少。这些材料理论上可以帮助两类人：

    * 没有资格获得Intel CNDA的个人或者机构，比如开源固件项目的维护者，这里请注意开源固件项目不可能直接受益于泄漏的内容因为有法律风险

     * 尝试理解复杂供应链的研究者

为数不多的信息来自git log，但依然无法确认其泄漏者：

因为泄漏的是Insyde方案（Insyde框架集成了Intel的资源），或许Insyde会知道更多的内容。

由于此次直接影响的机型并没有服务器，但介于服务器固件和桌面有共享部分code base，所以数据中心应该考虑：

短期方案：

    * 安全团队和补丁团队合作，保证关键设备升级到最新。

    * 安全运营团队加大对操作系统提权行为的监控和防护

    * 针对现有固件进行威胁检测和审计

长期方案：

    * 使用基于coreboot/oreboot的下一代固件框架替换UEFI

    * 配合安全载荷（比如VaultBoot，LinuxBoot等）实现芯片安全特性开箱

HardenedVault:

https://hardenedvault.net

Github:

https://github.com/hardenedvault