APIC/史诗！ 英特尔芯片泄露了内核不应该看到的秘密……

这是本周的 BWAIN，我们的诙谐术语 具有令人印象深刻的名字的错误.

BWAIN 是我们颁发的一项荣誉，当一个新的网络安全漏洞不仅变得有趣且重要，而且还出现了它自己的徽标、域名和网站时，我们就会授予它。

这个被称为 ÆPIC 泄漏, 双关语 APIC 和 EPIC.

前者是缩写 高级可编程中断控制器，而后者只是“史诗”这个词，如 巨人, 大规模, 极端, 巨型, 巨大的.

自撒克逊时代以来，字母 Æ 就没有在书面英语中使用过。 它的名字是 埃斯克，发音 灰 （如在树中），它几乎代表了现代单词 ASH 中 A 的声音。 但我们假设你应该发音这个词 ÆPIC 这里可以是“APIC-slash-EPIC”，也可以是“ah!-eh?-PIC”。

这到底是怎么回事？

所有这些都提出了五个有趣的问题：

• 什么是 APIC，为什么我需要它？
• 你怎么能有数据 甚至内核 不能偷看？
• 是什么导致了这场史诗般的失败 在 APIC 中？
• 是否 ÆPIC 泄漏 影响我?
• 该怎么办 关于它？

什么是 APIC？

让我们回到 1981 年，当时 IBM PC 首次出现。

PC 包括一个名为 Intel 8259A 可编程中断控制器，或图片。 （后来的模型，从 PC AT 开始，有两个 PIC，链接在一起，以支持更多的中断事件。）

PIC 的目的实际上是在发生需要立即注意的时间紧迫的事情时中断在 PC 中央处理器 (CPU) 上运行的程序。

这些硬件中断包括以下事件：键盘敲击； 接收字符的串口； 和一个重复的硬件计时器滴答作响。

如果没有这种硬件中断系统，操作系统将需要使用函数调用来定期检查传入的击键，当没有人打字但不会响应时，这将浪费 CPU 功率当他们这样做时就足够了。

可以想象，PIC 很快就出现了升级芯片，称为 APIC，一个 高级 CPU本身内置的某种PIC。

如今，APIC 提供的不仅仅是来自键盘、串行端口和系统计时器的反馈。

APIC 事件由过热等事件触发（并提供有关的实时数据），并允许当代多核处理器中不同内核之间的硬件交互。

而今天的英特尔芯片，如果我们可以大大简化，通常可以配置为以两种不同的方式工作，称为 xAPIC 模式 和 x2APIC 模式.

在这里， xAPIC 是从中断控制器中提取数据的“传统”方式，并且 x2APIC 是更现代的方式。

进一步简化，xAPIC 依赖于所谓的 多媒体输入输出， 短缺 内存映射输入/输出，用于在 APIC 注册感兴趣的事件时从 APIC 中读取数据。

在 MMIO 模式下，您可以通过读取特定内存区域 (RAM) 来找出触发 APIC 事件的原因，该内存区域反映了 APIC 芯片本身的输入/输出寄存器。

此 xAPIC 数据映射到计算机物理 RAM 中某处的 4096 字节内存块。

这简化了对数据的访问，但它需要在 APIC 芯片和系统内存之间进行烦人的、复杂的（并且，正如我们将看到的，具有潜在危险）的交互。

相反，x2APIC 要求您 直接读出APIC数据 从芯片本身，使用所谓的 特定型号寄存器 （MSR）。

根据英特尔的说法，避免该过程的 MMIO 部分 “提供显着提高的处理器寻址能力和中断传递的一些增强。”

值得注意的是，直接从片上寄存器中提取 APIC 数据意味着所支持的数据总量以及可同时管理的最大 CPU 内核数不限于 MMIO 模式下可用的 4096 字节。

你怎么会有连内核都看不到的数据呢？

您可能已经猜到，当您使用 xAPIC 模式时，最终进入 MMIO 内存区域的数据并不总是像应有的那样精心管理……

……因此，某种“数据泄漏”到 MMIO 区域是这个问题的核心。

但鉴于你 已经需要系统管理员级别的权限 首先读取 MMIO 数据，因此您几乎可以肯定无论如何都可以获取内存中的任何和所有数据……

…为什么在 APIC MMIO 数据区域中错误显示其他人的数据代表 史诗 泄漏？

它可能会使某些类型的数据窃取或 RAM 抓取攻击在实践中稍微容易一些，但它肯定不会为您提供更多理论上已经具备的内存侦听能力吗？

不幸的是，如果系统上的任何软件使用 Intel 的 SGX（简称 软件防护扩展.

---

了解更多关于新交所的信息

---

许多最新的 Intel CPU 都支持 SGX，它为操作系统内核提供了一种将代码和数据“密封”到 RAM 物理块中的方法，从而形成所谓的 enclave。

这使得它的行为至少暂时类似于手机中用于存储解密密钥等秘密的特殊安全芯片。

一旦设置了 enclave 的 SGX“锁”，只有在封闭的内存区域内运行的程序代码才能读取和写入该 RAM 的内容。

因此，在 enclave 激活后发生的任何计算的内部细节对于系统上的任何其他代码、线程、进程或用户都是不可见的。

包括内核本身。

有一种方法可以调用被密封在 enclave 中的代码，并且有一种方法可以返回它可能执行的计算的输出，但是没有办法恢复、监视或调试代码和它运行时的相关数据。

飞地实际上变成了一个黑匣子，您可以向其中提供输入（例如要使用私钥签名的数据），并提取输出（例如生成的数字签名），但您不能从中提取加密密钥在签名过程中使用。

可以想象，如果在使用 xAPIC“内存映射”模式时，本应密封在 SGX 飞地内的数据意外地被复制到用于“镜像”APIC 数据的 MMIO RAM 中……

…这将违反 SGX 的安全性，该安全性规定，在创建 SGX 飞地后，任何数据都不应该从 SGX 飞地中出现，除非它是由飞地本身已经运行的代码故意导出的。

是什么导致 APIC 出现这种史诗般的失败？

背后的研究人员 ÆPIC 泄漏纸 发现通过安排通过狡猾和不寻常的内存访问序列读取 APIC 数据......

…他们可以欺骗处理器填充 APIC MMIO 空间，不仅使用从 APIC 本身新接收的数据，而且还使用最近恰好被 CPU 用于其他目的的数据。

这种行为是一个副作用，尽管 APIC MMIO 内存页大小为 4096 字节，但 xAPIC 模式下的 APIC 芯片实际上并不会产生 4096 字节的数据，并且 CPU 并不总是正确中和首先用零填充 MMIO 区域的未使用部分。

相反，遗留在 CPU 缓存中的旧数据与从 APIC 芯片本身接收到的新数据一起被写出。

正如研究人员所说，这个错误归结为所谓的 未初始化的内存读取，您不小心重用了其他人在 RAM 中的剩余数据，因为他们和您都没有先将其从以前的秘密中清除。

ÆPIC 泄漏会影响我吗？

有关受影响芯片的完整列表，请参阅 英特尔自己的咨询.

据我们所知，如果您拥有第 10 代或第 11 代英特尔处理器，您可能会受到影响。

但是如果你有一个全新的第 12 代 CPU（在撰写本文时是最新的），那么似乎只有服务器级芯片会受到影响。

具有讽刺意味的是，在第 12 代笔记本电脑芯片中，英特尔已经放弃了 SGX，因此这个 bug 不适用，因为不可能有任何“密封”的 SGX 飞地可能泄漏。

当然，即使在潜在易受攻击的芯片上，如果您不依赖任何使用 SGX 的软件，那么该错误也不适用。

而这个错误，被称为 CVE-2022-21233, 只能被已经对您的计算机具有本地管理员级别 (root) 访问权限的攻击者利用。

普通用户 无法访问 APIC MMIO 数据块，因此根本无法窥探其中的任何内容，更不用说可能从 SGX 飞地泄露的秘密数据了。

也， 来宾虚拟机 (VM) 在 HyperV、VMWare 或 VirtualBox 等虚拟机管理程序中运行在主机操作系统的控制下，几乎可以肯定不能使用此技巧从其他来宾或主机本身窃取机密。

这是因为来宾虚拟机通常无法访问主机处理器中真正的 APIC 电路。 相反，每个来宾都有自己的模拟 APIC，该 APIC 是该 VM 独有的。

怎么办呢？

不要惊慌

在笔记本电脑或台式电脑上，您可能根本没有风险，因为您有一台旧的（或者，幸运的是，您是全新的！）计算机，或者因为您不依赖 SGX。

即使你有风险，任何以管理员/root 身份进入你的笔记本电脑的人都可能有足够的权力给你带来麻烦。

如果您有易受攻击的服务器并且您依赖 SGX 作为运营安全的一部分，请查看英特尔安全公告 英特尔-SA-00657 用于保护和缓解信息。

据撰写本文的研究人员称， “英特尔 [已经] 发布了微码和 SGX 软件开发套件更新来解决这个问题。”

Linux 内核团队现在似乎也在开发一个补丁，它允许您配置您的系统，以便它始终使用 x2APIC（正如您之前记得的那样，它不通过共享内存传输 APIC 数据），并且会优雅地防止系统在启动后被强制回到 xAPIC 模式。

---