关于Spectre和Meltdown的一则笑话【Intel，AMD & ARM】【2018开年巨献】

本文地址：http://www.moepc.net/?post=4048

更新ARM的声明

受影响的有如下几款ARM核心

Cortex-A75
Cortex-A73
Cortex-A72
Cortex-A57
Cortex-A17
Cortex-A15
Cortex-A9
Cortex-A8
Cortex-R8
Cortex-R7

所有受影响的ARM核心列表

Cortex-A系家谱，可以清楚地看到之间的联系。

1.列表外的ARM核心均不受影响。

2.对于Cortex-R，通常的应用模型处于非开放环境下，程序和进程严格受限，没有被攻击的可能

3.对于Spectre Variant 1，在你的代码里查找官方白皮书 – Cache Speculation Side-channels whitepaper里说到的code snippets，然后利用Compiler support for mitigations进行代码修改，然后用新编译器重编译。

页面地址：

https://developer.arm.com/support/security-update/download-the-whitepaper

https://developer.arm.com/support/security-update/compiler-support-for-mitigations

4.对于Spectre Variant 2，相应措施依架构而不同【…】：

Cortex-A57和Cortex-A72：打上所有内核和Arm Trusted Firmware补丁

Crotex-A73：打上所有内核和Arm Trusted Firmware补丁

Cortex-A75：打上所有内核和Arm Trusted Firmware补丁

内核补丁地址：https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti

Arm Trusted Firmware：https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6

5.对于Meltdown，ARM是这样形容的

Variant 3只在Cortex-A75上存在，解决需要打上所有内核补丁。不需要进一步检查或者修改内核以外的代码。

Variant 3a存在于Cortex-A15，Cortex-A57和Cortex-A72，ARM称没有必要采取软件措施。

====================早前的消息========================

首先从AMD的官方声明开始吧。本文表演的主角是Intel。

这次的漏洞有2个，1个是Spectre，1个是Meltdown，都是本地攻击漏洞，只能窃取信息，无法进行修改。

Spectre被利用的难度要求高于Meltdown，想完全修复也更难，允许一般程序盗取其他程序、系统内核或者hypervisor的信息。

Meltdown只存在于乱序执行的 Intel处理器【免于其难的只有Itanium和顺序执行的Atom – Saltwell和Bonnell】，更容易被利用所以威胁更高，Linux、Windows和macOS High Sierra针对Intel的修复补丁现已推出。Meltdown能让一般程序读取受保护的内核内存，从中窃取密码或其他重要信息。

早前关于Meltdown的文章：

Intel CPU的重大硬件安全bug “Meltdown”，修复后会降低最多30%性能【更新】
http://www.moepc.net/?post=4033

Spectre 分为Variant 1和Variant 2两种，

Meltdown是Variant 3。

根据AMD官方声明，只有Spectre的Variant 1在AMD平台上出现，只有打开eBPF JIT才可能受影响【默认是关闭的，必须通过net.core.bpf_jit_enable = 1打开才能攻击】。

可以通过软件/操作系统更新解决，对性能影响可忽略不计【原文措辞Negligble】

Spectre的Variant 2，对由于架构上的不同，对AMD处理器的威胁几乎为零。目前AMD处理器尚未发现受影响的可能，且Google团队未能成功用Variant2攻击AMD处理器【不排除后来发现的可能】

Variant 3，也就是Meltdown，仅限于Intel处理器，由于Intel处理器架构设计上的缺陷造成的

同样也是架构上的不同，AMD对此漏洞免疫。

也正因此Linux的漏洞补丁有这样的代码

所以AMD用户基本不用担心，Meltdown是Intel用户的事，Spectre也能通过系统更新修复，对性能不会有影响。

那么，Intel的反应？

对于Intel处理器，以上三种漏洞全部有效。

Spectre的补丁正在开发中，Intel声称可以通过OS和固件更新解决。

Intel发布了受Spectre Variant 2影响的处理器列表。包含Nehalem 及以后的所有主流架构，Silvermont及以后的所有的低功耗架构，还有Knights Landing及以后的所有至强众核。

亮点是，发布同时还反复强调AMD，ARM等其他厂家用户请联系各自的厂家，然而AMD并没有这个问题。

Intel Core i3 processor (45nm and 32nm)
Intel Core i5 processor (45nm and 32nm)
Intel Core i7 processor (45nm and 32nm)
Intel Core M processor family (45nm and 32nm)
2nd generation Intel Core processors
3rd generation Intel Core processors
4th generation Intel Core processors
5th generation Intel Core processors
6th generation Intel Core processors
7th generation Intel Core processors
8th generation Intel Core processors
Intel Core X-series Processor Family for Intel X99 platforms
Intel Core X-series Processor Family for Intel X299 platforms
Intel Xeon processor 3400 series
Intel Xeon processor 3600 series
Intel Xeon processor 5500 series
Intel Xeon processor 5600 series
Intel Xeon processor 6500 series
Intel Xeon processor 7500 series
Intel Xeon Processor E3 Family
Intel Xeon Processor E3 v2 Family
Intel Xeon Processor E3 v3 Family
Intel Xeon Processor E3 v4 Family
Intel Xeon Processor E3 v5 Family
Intel Xeon Processor E3 v6 Family
Intel Xeon Processor E5 Family
Intel Xeon Processor E5 v2 Family
Intel Xeon Processor E5 v3 Family
Intel Xeon Processor E5 v4 Family
Intel Xeon Processor E7 Family
Intel Xeon Processor E7 v2 Family
Intel Xeon Processor E7 v3 Family
Intel Xeon Processor E7 v4 Family
Intel Xeon Processor Scalable Family
Intel Xeon Phi Processor 3200, 5200, 7200 Series
Intel Atom Processor C Series
Intel Atom Processor E Series
Intel Atom Processor A Series
Intel Atom Processor x3 Series
Intel Atom Processor Z Series
Intel Celeron Processor J Series
Intel Celeron Processor N Series
Intel Pentium Processor J Series
Intel Pentium Processor N Series

Meltdown的补丁已经放出【PTI补丁】，但在某些情况下会极大地影响性能。

通常性能影响在个位数，平均5％；但最差的情况下性能会降低30％，比如大量syscall(系统调用) 和context switch(上下文切换) 。个别极端情况下会超过50%。【这是Phoronix今年1月3日在Linux 4.15的测试】

Windows的性能影响未知。

下面是Intel周三发布的PR。

正好theregister.co.uk的一篇文章，逐字逐句给它解析了一遍。

“Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed.“

翻译：要是恶意软件盗取了你的数据，对于Intel用户很正常，因为设计上就是这个样子的。当然，这也是我们股价下跌的原因。拜托也让其他友商的股价也跌一下，谢谢。

在这里引用了Linus Torvalds的评论【不知道是谁的去谷歌】

评论文字版：

【Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation doesn’t happen across protection domains. Maybe even a L1 I$ that is keyed by CPL.【一位*有能力的*CPU工程师可以解决这个问题】

I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.【Intel内部最好真的看看你们自己的设计，然后承认设计上有问题，而不是写一些PR来糊弄人说这是在正常工作。】

.. and that really means that all these mitigation patches should be written with “not all CPU’s are crap” in mind.【编写补丁的时候也要记住，“并不是所有的CPU都很烂” 【只有Intel】】

Or is Intel basically saying “we are committed to selling you shit forever and ever, and never fixing anything”?【或者说，Intel实际是在说“我们一直致力于卖给你们垃圾产品，从今往后都会这样，也不会去解决”】

Because if that’s the case, maybe we should start looking towards the ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:【两种可能】

 – Intel never intends to fix anything【1. Intel从没想过去修复】

OR

 – these workarounds should have a way to disable them. 【2. 这些解决方案要有关闭的手段】

Which of the two is it?

                   Linus】

Intel把Meltdown形容为 “Software analysis methods【软件分析手段】”
但研究者是这么形容的 “Meltdown breaks all security assumptions given by the CPU’s memory isolation capabilities.【你的“安全”完蛋了】”

“Intel believes these exploits do not have the potential to corrupt, modify or delete data.“

翻译：“破坏”、“篡改”、“删除”，看！多吓人！没关系！这些都是假的！人家没法修改你的数据！然后你就能忘掉这个漏洞是为了盗取你的数据的了。

“Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.“

翻译：别别别！千万别因为卖给你们有问题的产品，就跑去告我们或者让我们召回上百万的芯片。

Bug、漏洞、安全问题、设计缺陷、计划疏忽、架构失败。是一个东西。安全研究者把Meltdown形容为“微架构层面上的安全漏洞”，是实际硬件设计的问题。

“Based on the analysis to date, many types of computing devices ? with many different vendors’ processors and operating systems ? are susceptible to these exploits.“

翻译：不光我们一家。如果情况不妙，我们会把他们都一起拖下水。

Intel不想让你知道，1995年以来所有的Intel 乱序执行处理器，除了Itanium和顺序执行的Atom – Saltwell/Bonnel，都有这个漏洞。

“Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.”

翻译：#%$@#%！别来烦我。

Intel“可能”和AMD，ARM之类的在合作，但Meltdown并不会影响别人：AMD压根没有这bug，只有ARM的Cortex-A75怀疑有。性能降低是因为PTI补丁【现称KPTI，原名KAISER】，把内核放进独立的地址空间，不会被其他正在运行的进程访问。缺点是当程序需要内核帮忙做点啥的时候，比如读取文件和网络传输，CPU就需要在内核的虚拟地址空间之间切换，很花时间，大量切换就会导致性能降低。

Cortex-A75的KPTI Overhead目前无法得知，预计很小。

至于Intel系统，性能影响会在5-30%之间。【测试个别情况达到50%以上】

“Intel is committed to the industry best practice of responsible disclosure of potential security issues, which is why Intel and other vendors had planned to disclose this issue next week when more software and firmware updates will be available. However, Intel is making this statement today because of the current inaccurate media reports.”

翻译：我们本来准备下周发声明的，但这些王八蛋媒体提前走漏了风声，所以说，这些新闻都是假的！不存在的！

“Check with your operating system vendor or system manufacturer and apply any available updates as soon as they are available. Following good security practices that protect against malware in general will also help protect against possible exploitation until updates can be applied.“

翻译：傻X们，别瞎点不明来路的链接和邮件

“Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.”

翻译：不买我们的东西，你们还能上别处去？

One step below security by obscurity, there’s security by belief. Demand more. 

【2018/01/07更新: 新的Intel PR: https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html

虽然我们没办法完全解决漏洞，还会带来性能损失

但是我们可以教育用户如何重新认识“漏洞” !

??不要把它当做漏洞就好了。  It is not a bug. It’s a feature ! 

同时，Intel在去年六月就被谷歌告知了Meltdown的存在，然后十一月底Intel CEO Brian Krzanich卖掉了价值2400万美元的股票，只留下了25万股 – 仅高于Intel雇佣合同要求的最低值。

发布CoffeeLake之前当然也是知道的。

本文地址：http://www.moepc.net/?post=4048

下面是Google的调查机翻版，未校正

用侧通道读取特权内存

我们发现，CPU数据高速缓存时间可能会被滥用，以有效地泄漏错误推测的执行信息，导致（最坏的情况下）任意虚拟内存读取在各种情况下跨本地安全边界的漏洞。

这个问题的变种已知会影响许多现代处理器，包括英特尔，AMD和ARM的某些处理器。对于一些英特尔和AMD CPU型号，我们有攻击真正的软件的攻击。我们在2017-06-01向Intel，AMD和ARM报告了这个问题[1] 。

到目前为止，这个问题有三个已知变种：

变体1：边界检查旁路（CVE-2017-5753）
变体2：分支目标注入（CVE-2017-5715）
变体3：流氓数据缓存加载（CVE-2017-5754）

在此处所述的问题公开披露之前，Daniel Gruss，Moritz Lipp，Yuval Yarom，Paul Kocher，Daniel Genkin，Michael Schwarz，Mike Hamburg，Stefan Mangard，Thomas Prescher和Werner Haas也报告了这些问题。他们的[写作/博客帖子/论文稿]在：

幽灵（变种1和2）
崩溃（变体3）

在我们的研究过程中，我们开发了以下概念证明（PoC）：

PoC演示了经过测试的Intel Haswell Xeon CPU，AMD FX CPU，AMD PRO CPU和ARM Cortex A57 [2]中用户空间中的变体1的基本原理。这个PoC只能测试在同一个进程中错误推测执行的数据读取能力，而不会跨越任何特权边界。

对于版本1的PoC，在具有发行版标准配置的现代Linux内核下以普通用户权限运行时，可以在Intel Haswell Xeon CPU上的内核虚拟内存中的4GiB范围[3] 中执行任意读取。如果启用了内核的BPF JIT（非默认配置），那么它也适用于AMD PRO CPU。在Intel Haswell Xeon CPU上，大约4秒的启动时间后，内核虚拟内存可以以每秒2000字节的速度读取。[4]

对于版本2的PoC，在使用Intel Haswell Xeon CPU上的virt-manager创建的KVM guest虚拟机内以超级用户权限运行时，可以读取在主机上运行的特定（已过时）版本的Debian发行版内核[5]以1500字节/秒的速度托管内核内存，并具有优化空间。在执行攻击之前，对于具有64GiB RAM的机器，需要执行大约10到30分钟的初始化; 所需的时间应该与主机RAM的数量大致成线性关系。（如果客户可以使用2MB的大页面，初始化应该快得多，但是还没有经过测试。）

对于变种3的PoC，当以正常的用户权限运行时，可以在某种先决条件下读取Intel Haswell Xeon CPU上的内核内存。我们相信这个先决条件是目标内核内存在L1D缓存中。

有关这个主题的有趣资源，请看“文献”部分。

在这篇博文中关于处理器内部解释的警告：这篇博文包含了很多关于基于观察行为的硬件内部的猜测，这可能不一定对应于实际处理器。

我们对可能的缓解有一些想法，并向处理器供应商提供了一些想法。然而，我们相信处理器供应商的地位远比我们设计和评估缓解措施更好，我们期望他们成为权威指导的来源。

我们发送给CPU供应商的PoC代码和写法将在稍后提供。

经过测试的处理器

Intel（R）Xeon（R）CPU E5-1650 v3 @ 3.50GHz（本文档的其余部分称为“Intel Haswell Xeon CPU”）
AMD FX（tm）-8320八核处理器（本文档的其余部分称为“AMD FX CPU”）
AMD PRO A8-9600 R7,10个COMPUTE CORES 4C + 6G（本文档的其余部分称为“AMD PRO CPU”），
谷歌Nexus 5x手机的ARM Cortex A57内核[6] （本文档的其余部分称为“ARM Cortex A57”），

词汇表

退休：一个指令退出时，其结果，例如寄存器写入和内存写入，提交并使其他系统可见。指令可以不按顺序执行，但必须始终按顺序退出。

逻辑处理器核心：逻辑处理器核心是操作系统认为是处理器核心的东西。启用超线程后，逻辑核心的数量是物理核心数量的倍数。

缓存/未缓存的数据：在这篇博文中，“未缓存”的数据是仅存在于主存储器中的数据，而不是CPU的任何缓存水平。加载未缓存的数据通常需要超过100个CPU时间周期。

推测性执行：处理器可以执行经过分支而不知道是否将被采用或者其目标是何处，因此在知道它们是否应该被执行之前执行指令。如果这种推测结果是不正确的，那么CPU可以放弃没有架构效应的结果状态，并继续执行正确的执行路径。在知道它们处于正确的执行路径之前，指令不会退出。

错误猜测窗口：CPU推测性地执行错误代码并且还没有检测到发生错误猜测的时间窗口。

变体1：边界检查旁路

本节解释所有三种变体背后的常见理论，以及我们的变种1的PoC背后的理论，当在Debian发行版内核中的用户空间中运行时，可以在内核内存的4GiB区域中执行至少以下配置的任意读取：

Intel Haswell Xeon CPU，eBPF JIT已关闭（默认状态）

Intel Haswell Xeon CPU，eBPF JIT打开（非默认状态）

AMD PRO CPU，eBPF JIT打开（非默认状态）

eBPF JIT的状态可以使用net.core.bpf_jit_enable sysctl进行切换。

理论解释

“ 英特尔优化参考手册 ”在第2.3.2.3节（“分支预测”）中对以下有关Sandy Bridge（以及稍后的微架构修订版）

分支预测预测分支目标并启用
处理器在分支之前就开始执行指令
真正的执行路径是已知的。

在第2.3.5.2节（“L1 DCache”）中：

负载可以：
[…]
在前面的分支解决之前进行投机性的推测。
不按顺序和重叠的方式进行缓存未命中。

英特尔软件开发人员手册[7]在第3A卷第11.7节（“隐式高速缓存（Pentium 4，Intel Xeon和P6系列处理器）”中指出：

隐式高速缓存发生在内存元素可能被缓存的时候，尽管元素可能永远不会以正常的冯诺依曼序列被访问过。隐式高速缓存出现在P6和更新的处理器系列上，这是由于积极的预取，分支预测和TLB未命中处理。隐式缓存是现有Intel386，Intel486和Pentium处理器系统行为的延伸，因为在这些处理器系列上运行的软件也不能确定性地预测指令预取的行为。

考虑下面的代码示例。如果arr1-> length 未缓存，处理器可以推测性地从arr1-> data [untrusted_offset_from_caller] 加载数据。这是一个超出界限的阅读。这应该不重要，因为处理器将有效地回滚分支执行时的执行状态; 推测性执行的指令都不会退出（例如导致寄存器等被影响）。

struct array {
 unsigned long length;
 unsigned char data[];
};
struct array *arr1 = …;
unsigned long untrusted_offset_from_caller = …;
if (untrusted_offset_from_caller < arr1->length) {
 unsigned char value = arr1->data[untrusted_offset_from_caller];
 …
}

但是，在下面的代码示例中，有一个问题。如果arr1-> length ， arr2-> data [0x200]和arr2-> data [0x300] 没有被缓存，但是其他所有被访问的数据都是，并且分支条件被预测为true，处理器可以在arr1 之前进行如下推测- >长度已经被加载并且执行被重新引导：

load value = arr1 ->data [ untrusted_offset_from_caller ]

从arr2-> data中的数据相关偏移量开始加载，将相应的高速缓存行加载到L1高速缓存中

struct array {
 unsigned long length;
 unsigned char data[];
};
struct array *arr1 = …; /* small array */
struct array *arr2 = …; /* array of size 0x400 */
/* >0x400 (OUT OF BOUNDS!) */
unsigned long untrusted_offset_from_caller = …;
if (untrusted_offset_from_caller < arr1->length) {
 unsigned char value = arr1->data[untrusted_offset_from_caller];
 unsigned long index2 = ((value&1)*0x100)+0x200;
 if (index2 < arr2->length) {
   unsigned char value2 = arr2->data[index2];
 }
}

由于处理器注意到untrusted_offset_from_caller 大于arr1-> length ，执行返回到非推测路径后，包含arr2-> data [index2] 的缓存行停留在L1缓存中。通过测量加载arr2-> data [0x200] 和 arr2-> data [0x300] 所需的时间，攻击者可以确定在推测执行过程中index2 的值是0x200还是0x300，它揭示了arr1-> data [ untrusted_offset_from_caller ] ＆1 是0或1。

为了能够实际将这种行为用于攻击，攻击者需要能够在目标上下文中使用超出边界的索引来执行这样一个易受攻击的代码模式。为此，易受攻击的代码模式必须存在于现有代码中，或者必须有一个解释器或JIT引擎可用于生成易受攻击的代码模式。到目前为止，我们还没有确定任何现有的，可利用的弱势代码模式的实例; 使用变体1泄漏内核内存的PoC使用eBPF解释器或eBPF JIT引擎，它们内置在内核中，可供普通用户访问。

这样做的一个小的变体可能是使用一个越界读取函数指针来获取错误推测路径中的执行控制权。我们没有进一步调查这个变种。

攻击内核

本节将更详细地介绍如何使用eBPF字节码解释器和JIT引擎，使用变体1来泄漏Linux内核内存。尽管变种1攻击有许多有趣的潜在目标，但我们选择攻击Linux内核eBPF JIT /解释器，因为它比其他大多数JIT提供更多的对攻击者的控制。

Linux内核自3.18版本开始支持eBPF。未授权的用户空间代码可以将字节码提供给内核验证的内核，然后：

或者由内核字节码解释器解释

或翻译成本机机器码，该机器码也使用JIT引擎运行在内核上下文中（其翻译各个字节码指令而不执行任何进一步的优化）

字节码的执行可以通过将eBPF字节码作为过滤器附加到套接字上，然后通过套接字的另一端发送数据来触发。

JIT引擎是否启用取决于运行时配置设置 – 但至少在测试过的Intel处理器上，攻击独立于此设置工作。

与传统的BPF不同，eBPF具有数据类型，如数据数组和函数指针数组，eBPF字节码可以在其中进行索引。因此，可以使用eBPF字节码在内核中创建上述代码模式。

eBPF的数据数组比它的函数指针数组效率低，所以在可能的情况下攻击将使用后者。

两台机器都没有SMAP，PoC依赖于这个（但是原则上这不应该是一个先决条件）。

另外，至少在测试过的英特尔机器上，在内核之间弹出修改后的缓存行很慢，显然是因为MESI协议用于缓存一致性[8] 。在一个物理CPU内核上更改eBPF阵列的引用计数器会导致包含引用计数器的高速缓存行被跳转到该CPU内核，从而使所有其他CPU内核上的引用计数器的读取速度变慢，直到写入已更改的引用计数器回到记忆。由于eBPF阵列的长度和引用计数器存储在同一个高速缓存行中，这也意味着更改一个物理CPU内核上的引用计数器会导致eBPF阵列的长度读取在其他物理CPU内核上较慢（故意为false共享）。

这次袭击使用了两个eBPF程序。第一个通过页面对齐的eBPF函数指针数组prog_map 在可配置索引处尾部调用。在简化的计算，该程序被用于确定的地址prog_map 通过猜测从偏移prog_map 到用户空间地址和尾调用通过prog_map 在猜到偏移。为了使分支预测能够预测偏移量低于prog_map 的长度，尾调用一个入界索引。增加mis-speculation窗口，缓存行包含prog_map 的长度被反弹到另一个核心。为了测试偏移猜测是否成功，可以测试用户空间地址是否已经加载到缓存中。

由于地址的这种直接的蛮力猜测会很慢，所以使用以下优化：在用户空间地址user_mapping_area 处创建2 15个相邻用户空间存储器映射[9] ，每个由2 4个页面组成，覆盖总面积2 31 字节。每个映射映射相同的物理页面，并且所有映射都存在于页面表中。

这允许攻击以2 31 字节的步长进行。对于每个步骤，使通过外的边界访问之后prog_map 中，只有一个高速缓存线中的每个从所述第一2 4 页的user_mapping_area 必须对高速缓存的存储器测试。由于L3高速缓存物理地被索引，所以对映射物理页面的虚拟地址的任何访问都将导致映射同一物理页面的所有其他虚拟地址也被高速缓存。

当这种攻击发现一个命中的时候 – 一个缓存的内存位置 – 内核地址的高33位是已知的（因为它们可以从发生命中的地址猜测中得出），并且地址的低16位也是已知的（来自user_mapping_area 内找到命中的偏移量）。user_mapping_area 的地址的剩余部分是中间的。

中间剩余的位可以通过平分剩余的地址空间来确定：将两个物理页映射到相邻的虚拟地址范围，每个虚拟地址的范围是剩余搜索空间的一半的大小，然后逐位确定剩余的地址。

在这一点上，第二个eBPF程序可以用来实际泄漏数据。在伪代码中，这个程序如下所示：

uint64_t bitmask = <runtime-configurable>;
uint64_t bitshift_selector = <runtime-configurable>;
uint64_t prog_array_base_offset = <runtime-configurable>;
uint64_t secret_data_offset = <runtime-configurable>;
// index will be bounds-checked by the runtime,
// but the bounds check will be bypassed speculatively
uint64_t secret_data = bpf_map_read(array=victim_array, index=secret_data_offset);
// select a single bit, move it to a specific position, and add the base offset
uint64_t progmap_index = (((secret_data & bitmask) >> bitshift_selector) << 7) + prog_array_base_offset;
bpf_tail_call(prog_map, progmap_index);

该程序在运行时可配置的偏移量和位掩码处从eBPF数据阵列“ victim_map ”中读取8字节对齐的64位值，并对该值进行位移，使得一个位被映射到2个7 字节（当用作数组索引时足以不落入相同或相邻的缓存行）。最后，它添加一个64位的偏移量，然后使用结果值作为到prog_map 的偏移量来进行尾部调用。

这个程序可以用来通过反复调用eBPF程序来使内存泄漏到victim_map ，它指定要泄漏的数据以及在prog_map之内的一个超出边界的偏移量，从而导致prog_map + offset 指向用户空间内存区域。误导分支预测和弹跳高速缓存行的方式与第一个eBPF程序相同，除了现在，保存victim_map 长度的高速缓存行也必须被反弹到另一个核心。

变体2：分支目标注射

本节描述了我们的PoC的变体2的理论，当在使用Intel Haswell Xeon CPU上的virt-manager创建的KVM guest虚拟机内以超级用户权限运行时，可以读取主机上运行的特定版本的Debian distro内核内核内存的速度大约为1500字节/秒。

基本

之前的研究（见最后文献部分）已经表明，在不同安全上下文中的代码可能影响彼此的分支预测。到目前为止，这只是用来推断代码所在位置的信息（换句话说，是为了制造受害者对攻击者的干扰）。然而，这种攻击变体的基本假设是它也可以用来重定向受害者上下文中的代码的执行（换句话说，创建来自攻击者对受害者的干扰;反之亦然）。

攻击的基本思想是将包含目标地址从内存加载的间接分支的受害代码作为目标，并将包含目标地址的缓存行清除到主内存。然后，当CPU到达间接分支时，它不会知道跳转的真正目的地，并且在完成把高速缓存线加载回CPU之后，它将不能计算真正的目的地，几百个周期。因此，通常有超过100个周期的时间窗，其中CPU将基于分支预测推测性地执行指令。

Haswell分支预测内部

英特尔处理器实施的分支预测内部部分已经发布; 然而，让这种攻击正常工作需要进一步的实验来确定更多的细节。

本节重点介绍从Intel Haswell Xeon CPU实验获得的分支预测内部结构。

Haswell似乎有多个分支预测机制，工作方式非常不同：

通用分支预测器，每个源地址只能存储一个目标; 用于各种跳转，如绝对跳转，相对跳转等。

一个专门的间接调用预测器，可以为每个源地址存储多个目标; 用于间接呼叫。

（根据英特尔的优化手册，还有一个专门的回报预测器，但是我们还没有详细分析，如果这个预测器可以用来可靠地转储一些虚拟机进入的调用堆栈，非常有趣。）

通用预测

如先前研究中所记录的，通用分支预测器仅使用源指令的最后一个字节的地址的低31位来进行预测。例如，如果跳转从0x4141.0004.1000到0x4141.0004.5123存在分支目标缓冲区（BTB）条目，通用预测器也将使用它来预测从0x4242.0004.1000跳转。当源地址的高位如此不同时，预测目的地的高位与它一起改变 – 在这种情况下，预测的目标地址将是0x4242.0004.5123-显然，这个预测器不存储完整的绝对目的地地址。

在使用源地址的低31位来查找BTB条目之前，使用XOR将它们折叠在一起。具体而言，以下几位被折叠在一起：

换句话说，如果一个源地址与这个表中的一行中的两个数字异或，分支预测器在执行查找时将不能够将所得到的地址与原始源地址区分开来。例如，分支预测器可以区分源地址0x100.0000和0x180.0000，也可以区分源地址0x100.0000和0x180.8000，但不能区分源地址0x100.0000和0x140.2000或源地址0x100.0000和0x180.4000。在下文中，这将被称为别名源地址。

当使用别名源地址时，分支预测器仍将预测与未混淆源地址相同的目标。这表示分支预测器存储截断的绝对目标地址，但尚未验证。

根据观察到的不同源地址的最大前向和后向跳转距离，目标地址的低32位可以存储为绝对32位值，并附加一位，指定源到目标的跳转是否跨越2 32 边界; 如果跳转跨越这样的边界，则源地址的位31确定指令指针的高位一半是应该递增还是递减。

间接呼叫预测器

BTB查找这个机制的输入似乎是：

源指令地址的低12位（我们不确定它是第一个还是最后一个字节的地址）还是它们的一个子集。

分支历史缓冲区状态。

如果间接调用预测器无法解析分支，则由通用预测变量解析。英特尔的优化手册暗示了这种行为：“间接调用和跳转，这些可能被预测为具有单调目标或具有根据最近程序行为而变化的目标”。

分支历史缓冲区（BHB）存储关于最后29个采取的分支的信息 – 基本上是最近的控制流的指纹 – 并且被用来允许更好地预测可以具有多个目标的间接呼叫。

BHB的更新功能的工作原理如下（伪代码; src 是源指令的最后一个字节的地址，dst 是目标地址）：

void bhb_update(uint58_t *bhb_state, unsigned long src, unsigned long dst) {
 *bhb_state <<= 2;
 *bhb_state ^= (dst & 0x3f);
 *bhb_state ^= (src & 0xc0) >> 6;
 *bhb_state ^= (src & 0xc00) >> (10 – 2);
 *bhb_state ^= (src & 0xc000) >> (14 – 4);
 *bhb_state ^= (src & 0x30) << (6 – 4);
 *bhb_state ^= (src & 0x300) << (8 – 8);
 *bhb_state ^= (src & 0x3000) >> (12 – 10);
 *bhb_state ^= (src & 0x30000) >> (16 – 12);
 *bhb_state ^= (src & 0xc0000) >> (18 – 14);
}

当用于BTB访问时，BHB状态的一些位似乎被XOR进一步折叠在一起，但是精确的折叠功能尚未被理解。

BHB很有趣，有两个原因。首先，为了能够在间接呼叫预测器中准确地引起冲突，需要关于其近似行为的知识。但是它也允许在攻击者可以执行代码的任何可重复的程序状态下抛出BHB状态 – 例如，在攻击hypervisor之后，直接在hypercall之后。然后可以使用转储的BHB状态来指导管理程序，或者如果攻击者能够访问管理程序二进制，则确定管理程序加载地址的低20位（在KVM的情况下：加载地址的低20位kvm-intel.ko）。

反向工程分支预测器内部

本小节描述了我们如何反向设计Haswell分支预测器的内部。有些是从记忆中写下来的，因为我们没有详细记录我们正在做的事情。

我们最初尝试使用通用预测器对内核进行BTB注入，使用先前研究的知识，即通用预测器仅查看源地址的下半部分，并且仅存储部分目标地址。这种工作 – 然而，注射成功率很低，低于1％。（这是我们在方法2中使用的方法，用于对运行在Haswell上的修改的虚拟机管理程序进行初始化。

我们决定编写一个用户空间测试用例，以便能够更轻松地测试不同情况下的分支预测器行为。

基于分支预测器状态在超线程之间共享的假设[10]我们编写了一个程序，其中两个实例分别固定在运行在特定物理内核上的两个逻辑处理器中的一个，其中一个实例试图执行分支注入，而另一个实例测量分支注入成功的频率。这两个实例都是在禁用ASLR的情况下执行的，并且在相同的地址上具有相同的代码。注入过程对访问（每进程）测试变量的函数进行间接调用; 测量过程对函数进行间接调用，该函数根据时序测试每个进程的测试变量是否被缓存，然后使用CLFLUSH将其逐出。这两个间接呼叫都是通过相同的呼叫站点执行的。在每次间接调用之前，使用CLFLUSH将存储器中存储的函数指针刷新到主存储器，以扩大推测时间窗口。另外，

在这个测试中，注射成功率在99％以上，为我们今后的实验奠定基础。

然后，我们试图找出预测方案的细节。我们假定预测方案使用某种全局分支历史记录缓冲区。

为了确定分支信息保留在历史缓冲区中的持续时间，仅在两个程序实例中的一个中获取的条件分支被插入在一系列始终采用的条件跳转的前面，则始终采用条件跳转的数量跳跃（N）是变化的。结果是，对于N = 25，处理器能够区分分支（在1％以下的误预测率），但是对于N = 26，未能这样做（误预测率超过99％）。

因此，分支历史缓冲区必须能够存储关于至少最后的26个分支的信息。

两个程序实例之一中的代码随后在内存中移动。这揭示了只有源地址和目标地址的低20位对分支历史缓冲器有影响。

在两个程序实例中使用不同类型的分支进行测试表明，静态跳转，采用有条件的跳转，调用和返回对分支历史缓冲区的影响方式相同; 没有采取有条件的跳跃不影响它; 源指令的最后一个字节的地址是计数的地址; IRETQ不会影响历史缓冲区状态（这对测试很有用，因为它允许创建历史缓冲区不可见的程序流）。

在内存中间接调用多次之前移动最后的条件分支，显示分支历史缓冲区内容可以用来区分最后一个条件分支指令的许多不同位置。这表明历史缓冲区不存储小历史值列表; 相反，它似乎是历史数据混合在一起的更大的缓冲区。

然而，为了对分支预测有用，一个历史缓存需要在已经采用了一定数量的新分支之后“忘记”过去的分支。因此，当新的数据被混合到历史缓冲器中时，这不会导致已经存在于历史缓冲器中的比特中的信息向下传播 – 并且因此，信息的向上组合也可能不会很有用。考虑到分支预测也必须非常快，我们得出结论：历史缓冲区的更新功能可能左移旧历史缓冲区，然后XOR处于新状态（见图）。

如果这个假设是正确的，则历史缓冲区包含许多关于最近分支的信息，但是只包含与每个历史缓冲区更新关于包含任何数据的最后一个分支所移动的信息位数。因此，我们测试了翻转跳转的源地址和目标地址中的不同位，然后是带有静态源和目标的32个总是跳转的跳转，允许分支预测消除间接调用的歧义。[11]

中间有32个静态跳转，没有任何翻转似乎有影响，所以我们减少了静态跳转的次数，直到可以观察到差异。总共有28次跳转的结果是目标的0x1和0x2位以及0x40和0x80的源有这样的影响; 但是翻转目标中的0x1和源中的0x40或目标中的0x2和源中的0x80不允许消除歧义。这表明历史缓冲区的每插入移位是2位，并且显示哪些数据存储在历史缓冲区的最低有效位中。然后，我们在跳转位后通过减少固定跳转来重复这一点，以确定哪些信息存储在其余位中。

从KVM guest虚拟机读取主机内存

找到主机内核

我们的PoC分几步找到主机内核。下一步攻击确定和必要的信息包括：

低于kvm-intel.ko地址的20位

kvm.ko的完整地址

vmlinux的完整地址

回顾一下，这是不必要的复杂，但很好地演示了攻击者可以使用的各种技术。更简单的方法是首先确定vmlinux的地址，然后平分kvm.ko和kvm-intel.ko的地址。

在第一步，kvm-intel.ko的地址被泄露。为此，访客输入后的分支历史缓冲区状态被转出。然后，对于kvm-intel.ko的加载地址的位12..19的每个可能的值，历史缓冲器的预期最低16位是基于加载地址推测和最近8个分支的已知偏移量之前计算的来宾条目，并将结果与泄漏历史缓冲区状态的最低16位进行比较。

通过测量两个目标的间接调用的误预测率，分支历史缓冲器状态以2位为单位泄漏。间接调用的一种方式是从vmcall指令跟随一系列N个分支，其相关的源地址位和目标地址位都是零。间接调用的第二种方式是来自用户空间中的一系列受控分支，可用于将任意值写入分支历史缓冲区。

错误预测率如“反向工程分支预测器内部”部分所述进行测量，使用一个调用目标加载缓存行，另一个检查是否加载了相同的缓存行。

在N = 29的情况下，如果受控分支历史缓冲器值为零，则由于来自超级调用的所有历史缓冲器状态已被擦除，所以误预测将以高速率发生。在N = 28的情况下，如果受控分支历史缓冲器值是0 <<（28 * 2），1 <<（28 * 2），2 <<（28 * 2），3 <<（28） * 2） – 通过测试所有四种可能性，可以检测哪一个是正确的。那么，为了减少N的值，四种可能性是{0 | 1 | 2 | 3} <<（28 * 2）| （history_buffer_for（N + 1）>> 2）。通过重复此操作以减少N的值，可以确定N = 0的分支历史缓冲器值。

此时，kvm-intel.ko的低20位是已知的; 下一步是大致找到kvm.ko.

为此，使用通用分支预测器，使用插入到BTB中的数据，通过从kvm.ko到kvm-intel.ko的间接调用，发生在每个hypercall上; 这意味着间接调用的源地址必须从BTB中泄漏出去。

kvm.ko可能位于从0xffffffffc0000000 到0xffffffffc4000000 的范围内，页面对齐（0x1000）。这意味着“通用预测变量”一节中表格的前四项适用; 将有正确的2 4 -1 = 15混叠地址。但这也是一个优点：它将搜索空间从0x4000减少到0x4000 / 2 4 = 1024。

为了找到合适的源地址或其别名地址，通过特定寄存器加载数据的代码被放置在所有可能的调用目标（kvm-intel.ko的低20位泄漏加上模块的模块内偏移呼叫目标加2的倍数20 ）和间接呼叫被放置在所有可能的呼叫源。然后，交替执行超级调用，并通过不同的可能的非别名调用源执行间接调用，使用随机历史缓冲区状态，防止专用预测工作。在该步骤之后，有2种16 对于kvm.ko.的加载地址剩余的可能性

接下来，可以使用从vmlinux到kvm.ko的间接调用，以类似的方式确定vmlinux的加载地址。幸运的是，在vmlinux的加载地址中没有随机化的位被折叠在一起，所以不同于当定位kvm.ko时，结果将是唯一的。vmlinux具有2MiB的对齐和1GiB的随机化范围，所以仍然只有512个可能的地址。

因为（就我们所知），一个简单的超级调用实际上并不会导致从vmlinux到kvm.ko的间接调用，而是使用来自模拟串行端口的状态寄存器的端口I / O，一个用virt-manager创建的虚拟机。

剩下的唯一信息是kvm.ko的16个别名加载地址中的哪一个实际上是正确的。由于对kvm.ko的间接调用的源地址是已知的，因此可以使用二分法来解决：将代码放置在各种可能的目标上，根据代码的哪个实例被推测执行，加载两个缓存行中的一个，以及测量哪一个缓存行被加载。

识别缓存集

PoC假定虚拟机无权访问巨大的页面。为了发现具有相对于4KiB页面边界的特定对齐的所有L3缓存集合的驱逐集合，PoC首先分配25600页的内存。然后，在循环中，它选择所有剩余未排序页面的随机子集，使得子集中包含驱逐集合的集合的期望数目是1，通过重复访问其高速缓存行将每个子集合减小到驱逐集合测试缓存行是否总是被缓存（在这种情况下，它们可能不是驱逐集合的一部分），并尝试使用新的驱逐集合来驱逐所有剩余的未排序的缓存行，以确定它们是否在同一个缓存集合中[12 ]。

查找访客页面的主机虚拟地址

由于此攻击使用FLUSH + RELOAD方法泄漏数据，因此需要知道一个访客页面的主机内核虚拟地址。PRIME + PROBE等替代方法应该没有这个要求。

攻击这一步的基本思路是对管理程序使用分支目标注入攻击来加载攻击者控制的地址，并测试是否导致客户拥有的页面被加载。为此，可以使用从R8指定的内存位置进行简单加载的小工具 – 在该内核版本上达到访客退出后的第一个间接调用时，R8-R11仍包含访客控制的值。

我们期望攻击者需要知道在这一点上必须使用哪个驱逐集，或者同时暴力驱逐。然而，在实验上，使用随机驱逐集合也是如此。我们的理论是观察到的行为实际上是L1D和L2驱逐的结果，这可能足以允许几个指令值得投机执行。

主机内核映射（几乎？）物理内存区域中的所有物理内存，包括分配给KVM guest虚拟机的内存。然而，physmap的位置是随机的（1GiB对齐），在一个大小为128PiB的区域。因此，直接强制访客页面的主机虚拟地址需要很长时间。这不一定是不可能的; 作为一个估计值，应该可能在一天左右，或许更少，假设每秒12000次成功的注射和30个并行测试的客户页面; 但几分钟之内就没那么令人印象深刻了。

为了优化这个问题，可以分解这个问题：首先，使用可以从物理地址加载的小工具强制物理地址，然后暴力破坏physmap区域的基地址。因为通常可以假定物理地址远远低于128PiB，所以它可以被更有效地强制性地使用，并且之后强制physmap区域的基地址也更容易，因为可以使用具有1GiB对齐的地址猜测。

要蛮力的物理地址，可以使用下面的小工具：

这个小工具允许通过适当地设置R9从内核文本部分周围的区域加载一个8字节对齐的值，这尤其允许加载physmap 的起始地址page_offset_base。然后，原来在R8中的值 – 物理地址猜测减去0xf8 – 被加到前一次加载的结果，0xfa被加到它上面，结果被解除引用。

缓存集选择

为了选择正确的L3驱逐集，来自下一节的攻击基本上以不同的驱逐集执行，直到它工作。

泄露数据

在这一点上，通常有必要在主机内核代码中定位小工具，通过从攻击者控制的位置读取来实际泄漏数据，相应地移动和掩盖结果，然后将结果作为偏移量一个攻击者控制的负载地址。但是将小玩意拼凑在一起，搞清楚在猜测环境中哪些工作起作用似乎很烦人。因此，我们决定使用内置于主机内核的eBPF解释器，而在虚拟机内部没有合法的方法调用它，主机内核文本部分中的代码足以使其可用对于攻击，就像普通的ROP小工具一样。

eBPF解释器入口点具有以下功能签名：

static unsigned int __bpf_prog_run（void * ctx，const struct bpf_insn * insn）

第二个参数是指向要执行的静态预先验证的eBPF指令数组的指针 – 这意味着__bpf_prog_run（）不会执行任何类型的检查或边界检查。第一个参数只是作为初始模拟寄存器状态的一部分存储，所以它的值并不重要。

eBPF口译员除其他外提供：

多个仿真的64位寄存器

64位立即写入模拟寄存器

内存从存储在仿真寄存器中的地址读取

按位操作（包括位移）和算术运算

为了调用解释器入口点，给定R8-R11控制和受控数据在已知存储器位置的RSI和RIP控制的小工具是必需的。以下小工具提供了此功能：

现在，通过将R8和R9指向physmap中客户拥有的页面的映射，可以在主机内核中推测性地执行任意未经验证的eBPF字节码。然后，可以使用相对简单的字节码将数据泄漏到缓存中。

变种3：恶意数据缓存加载

基本上，阅读安德斯?福格的博文：https ://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/

总之，使用这个问题变体的攻击尝试从用户空间读取内核内存，而不会误导内核代码的控制流。这通过使用用于以前变体的代码模式，但在用户空间中起作用。其基本思想是，访问地址的权限检查可能不是从内存读取数据到寄存器的关键路径，权限检查可能会对性能产生重大影响。相反，内存读取可以使得读取的结果立即可用于以下指令，并且仅异步执行权限检查，在重新排序缓冲区中设置标志，如果权限检查失败，则会引发异常。

我们对Anders Fogh的博文有一些补充：

“想象一下在usermode中执行的下面的指令

mov rax，[somekernelmodeaddress]

退休时会造成中断，[…]“

在高延迟的预测错误分支后面也可以执行该指令，以避免发生页面错误。这也可以通过增加从核心地址读取和传送相关的异常之间的延迟来扩大猜测窗口。

“首先，我调用一个系统调用来触及这个内存;其次，我使用prefetcht0指令来提高我在L1中加载地址的几率。

当我们在系统调用之后使用预取指令时，攻击停止了对我们的工作，并且我们不知道为什么。也许CPU以某种方式存储访问是否在上次访问被拒绝，并防止攻击的工作，如果是这样的话？

“幸运的是，我没有得到一个缓慢的阅读暗示英特尔null的结果，当访问是不允许的。”

那（从内核地址读取返回全零）似乎发生的内存不足够缓存，但对于哪些可分页条目存在，至少在重复读取尝试。对于未映射的内存，内核地址读取根本不返回结果。

进一步研究的想法

我们相信我们的研究提供了许多尚未研究的剩余研究课题，我们鼓励其他公共研究人员研究这些课题。

这部分内容比这篇博文的其他内容还包含更多的猜测 – 它包含未经测试的想法，可能是没用的。

泄漏没有数据缓存时间

除了测量数据高速缓存时间之外，探讨是否存在微架构攻击将是有趣的，这些数据高速缓存时间可以用于从推测执行中渗出数据。

其他微架构

到目前为止，我们的研究相对以Haswell为中心。看到细节，例如其他现代处理器的分支预测如何工作，以及如何能够被攻击，这将是有趣的。

其他JIT引擎

我们针对内核中的JIT引擎开发了一个成功的变种1攻击。看看对系统控制较少的更先进的JIT引擎的攻击是否也是可行的，特别是JavaScript引擎是很有意思的。

更高效地扫描主机虚拟地址和缓存集

在变体2中，在扫描客户拥有的页面的主机虚拟地址的同时，尝试首先确定其L3缓存设置可能是有意义的。这可以通过使用通过physmap的逐出模式执行L3逐出，然后测试逐出是否影响客户拥有的页面来完成。

对于缓存集合也是一样的 – 使用L1D + L2驱逐集合来驱逐宿主内核上下文中的函数指针，使用内核中的小配件使用物理地址驱逐L3集合，然后使用它来确定哪些缓存设置了guest直到客人拥有的驱逐集已经建成。

倾倒完整的BTB状态

鉴于通用BTB似乎只能区分2 31-8个或更少的源地址，似乎可行的是在大约几个小时的时间周期内转储由例如hypercall生成的完整BTB状态。（扫描跳转源，然后为每个发现的跳转源，将跳转目标等分。）即使主机内核是定制的，也可能用于识别主机内核中函数的位置。

源地址别名会降低有用性，但由于目标地址不会受到这种影响，因此可能会从具有不同KASLR偏移量的机器关联（源，目标）对，并根据KASLR降低候选地址的数量加法，而混叠是按位。

这样就可能允许攻击者根据跳转偏移量或函数间的距离来猜测主机内核版本或编译器。

变种2：泄漏更有效的小工具

如果对变体2使用足够高效的小配件，则根本不需要从L3缓存驱逐主机内核功能指针; 只从L1D和L2驱逐它们可能就足够了。

各种加速

特别是变种2的PoC仍然有点慢。这可能部分是因为：

它一次只泄漏一点; 一次泄漏更多的应该是可行的。

它大量使用IRETQ来隐藏处理器的控制流。

使用变体2可以实现什么样的数据泄漏率是很有意思的。

通过回报预测器泄漏或注射

如果返回预测器在特权级别更改时也不会丢失状态，那么从VM内部定位主机内核可能非常有用（在这种情况下，可以使用二分法来快速发现主机内核的完整地址）或注入返回目标（特别是如果返回地址存储在缓存行中，可以被攻击者清除并且在返回指令之前不重新加载）。

然而，我们还没有对迄今为止取得确凿结果的回报预测因子进行任何实验。

从间接呼叫预测器泄漏数据

我们试图从间接呼叫预测器中泄漏目标信息，但一直无法使其工作。

供应商声明

Project Zero向他们透露了这个漏洞的供应商向我们提供了以下声明：

英特尔

目前没有提供当前的声明。

AMD

AMD提供了以下链接：http : //www.amd.com/en/corporate/speculative-execution

ARM

Arm认识到许多现代高性能处理器的推测功能，尽管按预期工作，可以结合缓存操作的时间来泄漏一些信息，如本博客中所述。相应地，Arm开发了我们推荐部署的软件缓解措施。

有关受影响的处理器和缓解措施的详细信息，请访问以下网站：https：//developer.arm.com/support/security-update

Arm包含了详细的技术白皮书，以及来自Arm架构合作伙伴关于其特定实施和缓解的信息的链接。

via：https://googleprojectzero.blogspot.jp/2018/01/reading-privileged-memory-with-side.html

https://www.amd.com/en/corporate/speculative-execution

https://lkml.org/lkml/2018/1/3/797

https://www.theregister.co.uk/2018/01/04/intels_spin_the_registers_annotations/

https://developer.arm.com/support/security-update

MOEPC.NET编译，转载请保留出处。