DRAM 相关故障（Rowhammer、SPOILER、RAMBleed、TRRespass、Half-Double）

动态随机存取存储器 (DRAM) 在计算机系统中提供CPU与程序运行数据存储。DRAM 芯片拥有数百万个存储单元，通常排列为二维阵列。存储单元由电容和晶体管组成。当电容存储电荷时，晶体管导通，每个存储单元可以保存1bit数据，由其电荷量（电压值）多少表示，正电荷（大于参考电压）表示值1，负电荷（小于参考电压）表示值0。通过激活某行控制线来访问一行中的存储单元。如果重复访问同一行内存，则每次都会激活和停用其控制线，这种重复激活、关闭可能出现DRAM故障。

什么是 DRAM 故障？

DRAM相关故障大致可以分为以下几类：

1. 从错误地址读取数据（地址错误）。
2. 数据写入了错误的地址。
3. 数据在读取时被破坏（即返回错误数据，但内存中的数据不变）。
4. 数据在写入时已损坏（即写入正确的地址，但存储了错误的数据位）。
5. 数据自动损坏，无需写入该内存地址（如电容漏电）。

DRAM 的“动态”部分是指需要定期刷新以避免数据错误（上面列表中的第 5 项），系统将在后台自动执行此刷新，刷新操作需要对电容充放电，并阻止对正在刷新的内存区域的访问，这也是为什么要尽量减少刷新的原因。

系统具有不同级别的 DRAM 故障保护。在硬件设计期间，模拟用于确保刷新操作足以防止数据损坏，并且内存总线不会损坏传输中的地址和数据（列表中的第 1 项到第 4 项）。当前的消费者系统通常根本不保护存储的数据，因为没有冗余，仅依赖于精心设计的内存刷新，许多服务器系统使用带有纠错码 (ECC) 的 DRAM，提高DRAM可靠性。

如何触发 DRAM 故障？

DRAM 故障可以自发发生，就像任何硬件故障一样，如果 DRAM 模块有缺陷或存在其他一些硬件缺陷，例如超出其规格运行的故障电源，则 DRAM 故障可能会以非常明显的速度发生并影响系统稳定性。

众所周知，某些内存访问模式更有可能暴露有缺陷的 DRAM 模块。memtest86+作为 Red Hat Enterprise Linux 一部分提供的RAM 测试器使用此类测试模式来暴露内存子系统中的硬件缺陷。

Rowhammer 攻击如何运作？

Rowhammer是指使用 CLFLUSH、CLFLUSHOPT 和 CLWB 系列 CPU 指令进行 DRAM 应力的特定技术。这一系列指令是由 i386 和 x86_64 架构提供的非特权指令，它们可以被滥用来增加到特定位置的 DRAM 流量。这使得编写 DRAM 故障诱导器特别有趣，这些程序可以作为普通进程在虚拟机管理程序中运行，因为 CLFLUSH 指令不需要特殊权限。

由 Rowhammer 引起的故障类型对应于初始列表中的第 5 项，存储的数据被更改，无需明确的内存写入，并且不一定在被访问的地址处，发生这种情况是因为访问模式使有关所需 DRAM 刷新率的设计假设无效：当以这种方式访问​​ DRAM 时，内存刷新发生的频率不足以可靠地保存存储的数据。

CLFLUSH 指令提供了一种特别有效的内存压力器，这对于许多系统来说都是困难的。CPU 提供其他方法（例如非临时内存访问）也可以绕过缓存，并且压力测试人员可以通过选择内存访问来达到非常相似的效果。

TRRespass (CVE-2020-10255)

为了缓解此类内存压力，系统供应商已在 DRAM 中构建了目标行刷新 (TRR) 机制。TRR 本质上刷新目标内存行以引发位翻转，从而避免通过 Rowhammer 效应自发的单元损坏。

该领域的最新研究表明，已发布的 TRR 机制不是单一的缓解措施，当然也不是修复所有 DRAM 或 Rowhammer 变体的机制。所述TRR保护机制可以在存储器控制器单元(MMU)中或在DRAM芯片内部实现。研究表明，在许多配备最新 DDR4 DRAM 芯片的新机器上，TRR 机制要么不存在，要么默认不启用，服务器类机器默认启用 TRR，而零售消费者机器可能没有，缓解措施似乎也没有涵盖整个内存地址空间。

TRR 保护机制仍然相当不透明，并且没有关于它如何保护 DRAM 免受众多 Rowhammer 变体影响的文档。为了克服围绕 TRR 的这种不透明性，构建了“TRRespass”工具，这是一个多面的 Rowhammer 模糊器，它可以帮助找到可能导致自发位损坏的更新的内存访问模式。

SPOILER：它与 Rowhammer 攻击有什么关系？

SPOILER 漏洞是一种微架构泄漏，允许攻击者确定非特权用户空间进程中的虚拟到物理页面映射。它利用内存顺序缓冲区中推测加载和存储操作的数据依赖性，并使用rdtscp和mfence指令来测量揭示内存布局的时序差异。允许检测连续物理内存页面的范围，使得 Rowhammer 更有效和更容易；只需几秒钟的攻击，而不是数周。

SPOILER 漏洞特定于 Intel CPU，从第一代 Intel Core 处理器开始就出现了，此漏洞与 Spectre 漏洞不同且独立，它可能会被 Web 浏览器执行的恶意 JavaScript 代码或系统上运行的不受信任的代码所利用。

RAMBleed

在当代全行业 DRAM 内存实现中发现了一个名为 RAMBleed CVE-2019-0174 的漏洞，该漏洞允许非特权攻击者通过利用 Rowhammer 位翻转效应读取属于其他进程的某些内存，否则读取的数据可能无法访问，并且可能包含潜在的秘密信息。RAMBleed 是一种旁道读取漏洞，因为 Rowhammer 引起的位翻转允许攻击者推断属于其他进程的内存中的位值，用精心构建的攻击者页面围绕受害者数据页面，在其上执行hammering 可以允许在攻击者控制的页面之一中引发相关数据位翻转，并重建数据。

与之前的 Rowhammer 攻击不同，RAMBleed 不需要使用大页面和巨大的TLB；概念验证代码可以每秒大约 3-4 位的速度读取内存。这种攻击不是特定于架构的，而且很多易受 Rowhammer 攻击的 DRAM 内存实现都易受 RAMBleed 攻击。

有一些常见的针对 Rowhammer 的基于硬件的缓解措施也有可能缓解 RAMBleed，这些是目标行刷新 (TRR)、增加的 DRAM 刷新间隔（DRAM 刷新率加倍）和 ECC 内存的使用。但是，这些策略实际缓解问题的程度各不相同，并且是特定于硬件平台的，预计供应商将提供合适的平台特定指导。

迄今为止，由于 ECC 内存的广泛使用增加了复杂性，因此尚未在服务器平台上证明这种攻击。然而，研究人员已经证明，理论上可以绕过 ECC，即使在存在 ECC 内存的情况下也能创建持续翻转，并对服务器进行攻击，也可能跨虚拟机进行攻击。虽然 ECC 内存确实使 Rowhammering 过程复杂化，但它不会阻止 Rowhammer，因此不会阻止 RAMBleed。

Half Double

row hammer攻击是通过访问与目标位相邻的 DRAM 行来攻击与被攻击的单元相邻行。Half-double 攻击证明，这种攻击可以基于对不直接在相邻邻居旁边的行的访问来影响目标单元，允许攻击者在他们的目标攻击中使用额外的行，并使现有的硬件缓解措施无效，这种半双攻击利用了硅的物理特性，并且随着内存芯片密度的增加而变得更加容易。

JEDEC 已经发布了两份关于 DRAM 和系统级缓解Half Double攻击技术的文件（JEP 300-1和JEP301-1）。

DRAM故障有什么影响？

内存是一个基本的系统组件；一切都取决于它的正确操作。因此，大多数 DRAM 故障都有可能破坏系统的正确运行，包括实施安全边界和关键数据，例如私钥材料。

如果发生此类故障，本地和远程攻击者都可能从中受益，本地攻击者可以更明确并触发 DRAM相关故障。

Sandboxing解决方案是否受到影响？

Java 和 JavaScript 沙盒不提供对 CLFLUSH 指令的访问，这意味着这种特定的 DRAM 压力变体将不起作用。然而，这两种语言的当前版本都提供了足够灵活的数据结构，因此有可能通过其他方式诱发 DRAM 故障。

SELinux 和容器不提供保护，因为它们在执行前不会拦截整个指令流，因此它们无法阻止诸如 CLFLUSH 之类的指令。

管理程序呢？

RHEV 等虚拟机管理程序目前不提供针对 DRAM 故障及其被滥用的保护。

Chrome 浏览器能够保护用户吗？

• -> https://nvd.nist.gov/vuln/detail/CVE-2015-0565

谷歌公开声称他们解决了与 Chrome 浏览器中的 DRAM 故障注入相关的漏洞，特别是在 Native Client 功能中。

Chrome 的 Native Client 组件使用受信任的编译器方法来执行从不受信任的来源下载的原生机器代码。指令流被扫描和审计，以寻找避免沙盒的危险指令。以前的 Chrome 版本允许 CLFLUSH 指令，该指令使基于 CLFLUSH 的 DRAM 故障诱导器能够运行，当前 Chrome 版本中的 Native Client 不允许 CLFLUSH，这阻止了这种方法的工作。

如上所述，CLFLUSH 不是强调 DRAM 所必需的，因此 Chrome 中的保护可能不完整，它仅适用于 Native Client 向量，可能还有其他方法可以通过 Web 浏览器触发 DRAM 故障，例如使用 JavaScript。

对于此类问题，是否可以使用基于软件的解决方案？

理论上可能可以将内存映射到虚拟机管理程序或操作系统进程，这样 Rowhammer 样式的 DRAM 故障注入仅影响同一安全域（用户或程序）内的数据。由于以下几个原因，这在实践中不太可能可行：

• 有必要禁用跨安全边界的只读页面共享（例如内核同页合并或进程之间共享的只读映射），从而大大降低系统负载密度。
• 该机制高度依赖于内存配置，并且仅对非常特定的系统配置有效，具体取决于 CPU 芯片和微代码版本、系统固件版本、主板版本等。

即使在今天，在具有此类设施的系统上，也可以mcelog使用包中的edac-util命令来监视 MCE 事件的发生（使用），尤其是 EDAC（错误检测和纠正）计数器edac-utils。这些工具可用于在可利用的 DRAM 故障发生之前发现与 DRAM 相关的系统退化的早期迹象。

客户应对DRAM故障怎么办？

DRAM 故障是硬件供应商需要解决的问题，需要拥有足够的设计储备和 ECC 内存等技术。