点击蓝字 关注我们
CPU微码安全杂谈
引言
在现代计算机系统中,处理器(CPU)是整个系统的核心,其性能和安全性直接影响计算机的整体表现。毫不夸张地说,作为人类造物的巅峰,CPU是人类数学、物理、化学等多个领域最高研究成果的结晶。
(图为Intel Haswell-E处理器在显微镜下的照片,来源于互联网)
我们在纳米尺度上完成各种器件的蚀刻,最终完成这幅令⼈震撼的艺术品,并且量产出来让它⾛进千家万户,这是多么伟⼤的成就。但人类毕竟不是上帝,即使是⼈造物的巅峰之作仍然⽆法逃脱出bug的命运。
几乎所有现代CPU厂商都有设计和生产瑕疵的历史,从相关设计稳定性问题到潜在的安全漏洞。例如,1994年Intel奔腾处理器(Pentium)中“FDIV Bug”,当时的英特尔奔腾处理器上发现的⼀个浮点除法运算错误,这个错误是由于处理器在执行浮点数除法时使⽤的查找表中存在缺陷,导致某些特定情况下的除法运算结果不准确。去年著名的“硬件考古学家”Ken Shirriff[1]用显微镜重新对存在bug的奔腾处理器进行了分析,发现了这⼀bug的根本原因。
FDIV Bug源于Pentium处理器的浮点运算单元,该单元采⽤了SRT除法算法,使其计算速度显著超过当时的其他处理器。该算法依赖于⼀个包含2048个单元的查找表,其结果由特定晶体管的存在或缺失决定。根据Shirriff的调查,表中缺少了五个关键晶体管,导致了错误的计算结果。更有趣的是,他还发现了另外11个缺失的数据点,但这些缺失点并未影响计算结果,这种现象被称为“运气使然”。这种偶然性与缺陷的复杂性相结合,使得当时几乎无法及时识别出这⼀问题。
最终,这⼀技术故障导致Intel不得不召回产品,造成近5亿美⾦的损失,以及恶劣的品牌影响。在之后的⼀年,CPU厂商便引入了微码技术来应对CPU补丁和升级的问题。
01
什么是微码
微指令(microcode),或称微码,是⼀种在复杂指令集计算(CISC)架构中,将复杂指令分解为⼀系列简单指令的技术。这⼀概念最早出现于1947年。
微指令的主要功能是将机器指令的设计与电路实现分离,这样设计者可以在不受电路架构限制的情况下自由修改机器指令。通过微指令,设计者能够在降低电路复杂度的同时,实现复杂的多步骤机器指令。撰写微指令的过程被称为微程序设计(microprogramming),而在特定架构的处理器实现中,这些微指令有时被称为微程序(microprogram)。
现代微指令通常由CPU⼯程师在设计阶段编写,并存储在只读存储器(ROM)或可编程逻辑阵列(PLA)中。不过,有些机器将微指令存储在静态随机存取存储器(SRAM)或闪存(flash memory)中。微指令对于普通程序员甚至汇编语⾔程序员来说通常是不可见且不可修改的。与机器指令不同,微指令不需要在不同处理器之间保持兼容性,而是专为特定电路架构设计,成为特定处理器设计的⼀部分。
在CPU初始化时,系统BIOS负责将CPU厂商提供的微码加载到CPU中。即使操作系统尚未运⾏,Linux内核也可以在引导时更新CPU固件,而无需更新BIOS。处理器的微码保存在内存中,并可以在每次系统启动时由内核更新。来自Intel或AMD的微码更新可以通过修复bug或应用补丁来提⾼处理器的稳定性和安全性。
微码类似于CPU指令的驱动程序。在现代CPU中,⼀条CPU指令由微码转换成适合该CPU型号的微操作(Micro-ops/uops),这些微操作指导CPU电路完成汇编指令的要求。CPU中有专门的硬件解码器将汇编指令翻译成微操作,微码解码器作为查找表(Lookup Table)存储在ROM中,用于解码复杂指令,如浮点运算指令。通常,硬件解码器解码速度较快,而微码解码速度较慢。
(某CPU架构图,来⾃Defcon 31, Backdoor in core)
理论上,如果能更改某处理器的微码,就可以将通过它翻译的指令变成任意其他指令。因此,现代微码升级主要⽤于解决处理器的稳定性和安全性问题。
02
微码更新工作原理
了解了什么是微码,以及它是如何工作的之后,我们来看⼀下在现代计算机中微码是如何更新的。这里以Intel为例。
⾸先,微码更新涉及将Intel提供的特定⼆进制代码写⼊⼀个型号特定的寄存器(MSR),即IA32_UCODE_WRITE。这⼀操作需要特权,通常由BIOS在系统启动时完成。更新的⼆进制代码格式未公开,因此对其进⾏详细研究和修改是⾮常困难的。
在应⽤更新之前,BIOS或操作系统必须验证更新与当前硬件的匹配性。每个微码更新都附带⼀个头部,其中包含了更新的元数据,包括微码版本号、处理器签名和处理器标志。这些信息用于验证更新是否适用于当前的处理器型号。微码版本号是递增的,只有在当前微码版本低于更新版本时,更新才能成功应用。BIOS通常通过读取IA32_UCODE_REV寄存器来获取当前微码版本,并与新更新的版本进⾏比较。
处理器签名是硬件型号的唯⼀标识符,可以通过CPUID指令获取当前硬件的签名。BIOS或操作系统将此签名与微码头部提供的签名进行比较,以确保更新适用于该处理器。此外,处理器标志字段结合平台ID位⽤于进⼀步验证更新的适⽤性。⼀旦验证通过,BIOS会将更新的虚拟地址写⼊IA32_UCODE_WRITE寄存器。这⼀操作完成后,BIOS通常会再次执⾏CPUID指令,并读取IA32_UCODE_REV寄存器,以确认微码版本号是否已更新。这⼀检查确保更新已成功应⽤。
微码更新的设计确保了只有经过验证的更新才能被应⽤,从而提⾼了处理器的稳定性和安全性。这⼀过程的重要性在于它能修复设计和实现中的缺陷,防止潜在的稳定性问题或安全漏洞。尽管微码更新的具体格式未公开,研究表明,更新⽂件中包含⽤于验证完整性和真实性的加密签名。这种设计不仅保护了更新的安全性,也防止了未经授权的代码被注⼊处理器。通过这些措施,微码更新为处理器的稳定性和安全性提供了重要保障。
03
微码相关安全研究
微码的强大能力暴露处理器安全的⼀个新的攻击面,针对微码的安全研究也成为了热点。这⾥笔者列举了最近两个印象比较深刻的研究,目前笔者读到的关于微码安全相关的研究与分析可以追溯到2004年以前,有兴趣的读者可以自行考古。
1
Google的bug hunters团队近期披露的⼀个AMD处理微码更新的高危漏洞CVE-2024-56161,由于AMD Zen架构的微码签名验证算法设计不当,使得攻击者有可能通过特定的⽅式伪造签名构造微码更新⽂件,该漏洞影响了几乎AMD从服务器到消费级的所有主流CPU。
根据Google的研究⼈员所披露的信息,研究人员发现,AMD Zen架构中使用的AES-CMAC密钥与NIST SP 800-38B文档中的示例密钥相同。这意味着这个密钥并非完全随机⽣成,而是可能在多个CPU中重复使⽤。更糟糕的是,AMD Zen架构的微码签名验证过程中,使用了CMAC(Cipher-based Message Authentication Code)作为哈希函数。而CMAC本质上是⼀种消息认证码,不具备加密哈希函数的所有安全特性,特别是在防止哈希碰撞方面。攻击者可以利⽤CMAC的特性来伪造签名,从⽽⽣成伪造的微码更新⽂件并绕过签名验证过程。
在研究过程中,Google的研究团队开发了⼀套名为zentool的工具,极⼤地推动了微码分析和攻击模拟的进展。zentool提供了以下能力:
1. 微码补丁检查:允许研究人员对微码进行有限的反汇编和分析,帮助理解微码的结构和功能。
2. 微码补丁创建:提供了⼀些逆向工程的汇编功能,使研究⼈员能够创建和修改微码补丁。
3. 微码补丁签名:支持使用伪造的RSA密钥对微码补丁进行签名,使其看起来像是合法的AMD补丁。
4. 微码补丁加载:通过标准的微码加载技术,将自定义的微码补丁应⽤到CPU上。
2
Backdoor in core
2023年Defcon 31上,来自vectorize的两位安全研究⼈员基于对Intel Goldmont CPU的研究,成功逆向⼯程了复杂x86指令的实现,发现了隐藏的微代码,这些微代码用于防止任何更改的持久化。利用这些知识,他们能够修补这些发现的部分,从而允许他们实现在Linux⽤户空间中进⾏持久的微代码更改。他们还开发并改进了微代码跟踪⼯具,使研究人员能够比以前更深入地了解Intel Atom微代码,并通过允许对ROM进行更动态的分析。
此外,他们还提供了⼀个用于进行微代码更改的C库和逆向⼯程微代码的⽂档,并展示了厂商对微代码的更新无法被用户验证可能带来安全风险的事实。他们在⼀台开发版的Intel主机上演示了通过微码修改syscall的行为来植入后门,在write系统调用发⽣时通过对buffer内容的检查触发执行其他程序。最后,他们展示了如何通过网络远程触发这⼀过程,赢得了全场的喝采。
04
展望
微码在处理器安全中发挥了重要作⽤,但其安全性也⾯临挑战:
1. 不可见性:微码通常是闭源的,制造商对其进⾏严格保密。这种不可见性使得研究⼈员很难分析和发现潜在的安全漏洞。
2. 复杂性:现代处理器架构复杂,微码的更新可能会影响多个处理器功能模块,增加了安全分析的难度。
3. 更新机制的安全性:微码更新通常通过固件更新的⽅式进行,但这种更新机制可能被恶意利用,导致安全风险。
随着处理器技术的不断发展,微码的安全性将成为影响系统整体安全的重要因素。笔者认为,未来如果能推动开放微码架构的研究,能使更多研究人员参与到微码安全的分析和改进中,并通过引入形式化验证⼯具,用于减少微码漏洞和bug,这些措施可以大幅提高微码安全性。
05
参考链接
1. Ken Shirriff的blog:https://www.righto.com/
2. https://jenda.hrach.eu/f2/hawkes_intel_microcode.pdf
3. CVE-2024-56161:https://bughunters.google.com/blog/5424842357473280/zen-and-the-artof-microcode-hacking
4. zentool:https://github.com/google/security-research/tree/master/pocs/cpus/entrysign/zentool
5. Backdoor in core:https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20presentations/Alex ander%20Dalsgaard%20Krog%20Alexander%20Skovsende%20-
%20Backdoor%20in%20the%20Core%20-
%20Altering%20the%20Intel%20x86%20Instruction%20Set%20at%20Runtime.pdf
6. Anonymous. 2004. Opteron Exposed: Reverse Engineering AMD K8 Microcode Updates:https://www.realworldtech.com/forum/?threadid=35566&curpostid=35566
往期精彩合集
● LLM应用安全风险演进:OWASP LLM应用Top10风险2023版与2025版对比分析
● LLM越狱防御术
长
按
关
注
联想GIC全球安全实验室(中国)
原文始发于微信公众号(联想全球安全实验室):CPU微码安全杂谈
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论