mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
98 lines
14 KiB
Markdown
98 lines
14 KiB
Markdown
Intel 设计缺陷背后的原因是什么？
|
||
============================================================
|
||
|
||
> 我们知道有问题，但是并不知道问题的详细情况。
|
||
|
||
|
||
|
||
（本文发表于 1 月份）最近 Windows 和 Linux 都发送了重大安全更新，为防范这个尚未完全公开的问题，在最坏的情况下，它可能会导致性能下降多达一半。
|
||
|
||
在过去的几周，Linux 内核陆续打了几个补丁。Microsoft [自 11 月份开始也内部测试了 Windows 更新][3]，并且它预计在下周二的例行补丁中将这个改进推送到主流 Windows 构建版中。Microsoft 的 Azure 也在下周的维护窗口中做好了安排，而 Amazon 的 AWS 也安排在周五对相关的设施进行维护。
|
||
|
||
自从 Linux 第一个补丁 （参见 [KPTI：内核页表隔离的当前的发展][4]） 明确描绘了出现的错误以后。虽然 Linux 和 Windows 基于不同的考虑，对此持有不同的看法，但是这两个操作系统 —— 当然还有其它的 x86 操作系统，比如 FreeBSD 和 [macOS][5] — 对系统内存的处理采用了相同的方式，因为对于操作系统在这一部分特性是与底层的处理器高度耦合的。
|
||
|
||
### 保持地址跟踪
|
||
|
||
在一个系统中的每个内存字节都是隐性编码的，这些编码数字是每个字节的地址。早期的操作系统使用物理内存地址，但是，物理内存地址由于各种原因，它并不很合适。例如，在地址中经常会有空隙，并且（尤其是 32 位的系统上）物理地址很难操作，需要 36 位数字，甚至更多。
|
||
|
||
因此，现在操作系统完全依赖一个叫虚拟内存的概念。虚拟内存系统允许程序和内核一起在一个简单、清晰、统一的环境中各自去操作。而不是使用空隙和其它奇怪的东西的物理内存，每个程序和内核自身都使用虚拟地址去访问内存。这些虚拟地址是连续的 —— 不用担心有空隙 —— 并且合适的大小也更便于操作。32 位的程序仅可以看到 32 位的地址，而不用管物理地址是 36 位还是更多位。
|
||
|
||
虽然虚拟地址对每个软件几乎是透明的，但是，处理器最终还是需要知道虚拟地址引用的物理地址是哪个。因此，有一个虚拟地址到物理地址的映射，它保存在一个被称为页面表的数据结构中。操作系统构建页面表，使用一个由处理器决定的布局，并且处理器和操作系统在虚拟地址和物理地址之间进行转换时就需要用到页面表。
|
||
|
||
这个映射过程是非常重要的，它也是现代操作系统和处理器的重要基础，处理器有专用的缓存 — Translation Lookaside Buffer（简称 TLB）—— 它保存了一定数量的虚拟地址到物理地址的映射，这样就不需要每次都使用全部页面。
|
||
|
||
虚拟内存的使用为我们提供了很多除了简单寻址之外的有用的特性。其中最主要的是，每个程序都有了自己独立的一组虚拟地址，有了它自己的一组虚拟地址到物理地址的映射。这就是用于提供“内存保护”的关键技术，一个程序不能破坏或者篡改其它程序使用的内存，因为其它程序的内存并不在它的地址映射范围之内。
|
||
|
||
由于每个进程使用一个单独的映射，因此每个程序也就有了一个额外的页面表，这就使得 TLB 缓存很拥挤。TLB 并不大 —— 一般情况下总共可以容纳几百个映射 —— 而系统使用的页面表越多，TLB 能够包含的任何特定的虚拟地址到物理地址的映射就越少。
|
||
|
||
### 一半一半
|
||
|
||
为了更好地使用 TLB，每个主流的操作系统都将虚拟地址范围一分为二。一半用于程序；另一半用于内核。当进程切换时，仅有一半的页面表条目发生变化 —— 仅属于程序的那一半。内核的那一半是每个程序公用的（因为只有一个内核）并且因此它可以为每个进程使用相同的页面表映射。这对 TLB 的帮助非常大；虽然它仍然会丢弃属于进程的那一半内存地址映射；但是它还保持着另一半属于内核的映射。
|
||
|
||
这种设计并不是一成不变的。在 Linux 上做了一项工作，使它可以为一个 32 位的进程提供整个地址范围，而不用在内核页面表和每个进程之间共享。虽然这样为程序提供了更多的地址空间，但这是以牺牲性能为代价的，因为每次内核代码需要运行时，TLB 重新加载内核的页面表条目。因此，这种方法并没有广泛应用到 x86 的系统上。
|
||
|
||
在内核和每个程序之间分割虚拟地址的这种做法的一个负面影响是，内存保护被削弱了。如果内核有它自己的一组页面表和虚拟地址，它将在不同的程序之间提供相同的保护；内核内存将是简单的不可见。但是使用地址分割之后，用户程序和内核使用了相同的地址范围，并且从原理上来说，一个用户程序有可能去读写内核内存。
|
||
|
||
为避免这种明显不好的情况，处理器和虚拟地址系统有一个 “Ring” 或者 “模式”的概念。x86 处理器有许多 Ring，但是对于这个问题，仅有两个是相关的：“user” （Ring 3）和 “supervisor”（ring 0）。当运行普通的用户程序时，处理器将置为用户模式 （Ring 3）。当运行内核代码时，处理器将处于 Ring 0 —— supervisor 模式，也称为内核模式。
|
||
|
||
这些 Ring 也用于从用户程序中保护内核内存。页面表并不仅仅有虚拟地址到物理地址的映射；它也包含关于这些地址的元数据，包含哪个 Ring 可能访问哪个地址的信息。内核页面表条目被标记为仅有 Ring 0 可以访问；程序的条目被标记为任何 Ring 都可以访问。如果一个处于 Ring 3 中的进程去尝试访问标记为 Ring 0 的内存，处理器将阻止这个访问并生成一个意外错误信息。运行在 Ring 3 中的用户程序不能得到内核以及运行在 Ring 0 内存中的任何东西。
|
||
|
||
至少理论上是这样的。大量的补丁和更新表明，这个地方已经被突破了。这就是最大的谜团所在。
|
||
|
||
### Ring 间迁移
|
||
|
||
这就是我们所知道的。每个现代处理器都执行一定数量的推测运行。例如，给一些指令，让两个数加起来，然后将结果保存在内存中，在查明内存中的目标是否可访问和可写入之前，一个处理器可能已经推测性地做了加法。在一些常见案例中，在地址可写入的地方，处理器节省了一些时间，因为它以并行方式计算出内存中的目标是什么。如果它发现目标位置不可写入 —— 例如，一个程序尝试去写入到一个没有映射的地址或压根就不存在的物理位置 —— 然后它将产生一个意外错误，而推测运行就白做了。
|
||
|
||
Intel 处理器，尤其是（[虽然不是 AMD 的][6]）允许对 Ring 3 代码进行推测运行并写入到 Ring 0 内存中的处理器上。处理器并不完全阻止这种写入，但是推测运行轻微扰乱了处理器状态，因为，为了查明目标位置是否可写入，某些数据已经被加载到缓存和 TLB 中。这又意味着一些操作可能快几个周期，或者慢几个周期，这取决于它们所需要的数据是否仍然在缓存中。除此之外，Intel 的处理器还有一些特殊的功能，比如，在 Skylake 处理器上引入的软件保护扩展（SGX）指令，它改变了一点点访问内存的方式。同样的，处理器仍然是保护 Ring 0 的内存不被来自 Ring 3 的程序所访问，但是同样的，它的缓存和其它内部状态已经发生了变化，产生了可测量的差异。
|
||
|
||
我们至今仍然并不知道具体的情况，到底有多少内核的内存信息泄露给了用户程序，或者信息泄露的情况有多容易发生。以及有哪些 Intel 处理器会受到影响？也或者并不完全清楚，但是，有迹象表明每个 Intel 芯片都使用了推测运行（是自 1995 年 Pentium Pro 以来的所有主流处理器吗？），它们都可能会因此而泄露信息。
|
||
|
||
这个问题第一次被披露是由来自 [奥地利的 Graz Technical University][7] 的研究者。他们披露的信息表明这个问题已经足够破坏内核模式地址空间布局随机化（内核 ASLR，或称 KASLR）。ASLR 是防范 [缓冲区溢出][8] 漏洞利用的最后一道防线。启用 ASLR 之后，程序和它们的数据被置于随机的内存地址中，它将使一些安全漏洞利用更加困难。KASLR 将这种随机化应用到内核中，这样就使内核的数据（包括页面表）和代码也随机化分布。
|
||
|
||
Graz 的研究者开发了 [KAISER][9]，一组防范这个问题的 Linux 内核补丁。
|
||
|
||
如果这个问题正好使 ASLR 的随机化被破坏了，这或许将成为一个巨大的灾难。ASLR 是一个非常强大的保护措施，但是它并不是完美的，这意味着对于黑客来说将是一个很大的障碍，一个无法逾越的障碍。整个行业对此的反应是 —— Windows 和 Linux 都有一个非常重要的变化，秘密开发 —— 这表明不仅是 ASLR 被破坏了，而且从内核泄露出信息的更普遍的技术被开发出来了。确实是这样的，研究者已经 [在 Twitter 上发布信息][10]，他们已经可以随意泄露和读取内核数据了。另一种可能是，漏洞可能被用于从虚拟机中“越狱”，并可能会危及 hypervisor。
|
||
|
||
Windows 和 Linux 选择的解决方案是非常相似的，将 KAISER 分为两个区域：内核页面表的条目不再是由每个进程共享。在 Linux 中，这被称为内核页面表隔离（KPTI）。
|
||
|
||
应用补丁后，内存地址仍然被一分为二：这样使内核的那一半几乎是空的。当然它并不是非常的空，因为一些内核片断需要永久映射，不论进程是运行在 Ring 3 还是 Ring 0 中，它都几乎是空的。这意味着如果恶意用户程序尝试去探测内核内存以及泄露信息，它将会失败 —— 因为那里几乎没有信息。而真正的内核页面中只有当内核自身运行的时刻它才能被用到。
|
||
|
||
这样做就破坏了最初将地址空间分割的理由。现在，每次切换到用户程序时，TLB 需要实时去清除与内核页面表相关的所有条目，这样就失去了启用分割带来的性能提升。
|
||
|
||
影响的具体大小取决于工作负载。每当一个程序被调入到内核 —— 从磁盘读入、发送数据到网络、打开一个文件等等 —— 这种调用的成本可能会增加一点点，因为它强制 TLB 清除了缓存并实时加载内核页面表。不使用内核的程序可能会观测到 2 - 3 个百分点的性能影响 —— 这里仍然有一些开销，因为内核仍然是偶尔会运行去处理一些事情，比如多任务等等。
|
||
|
||
但是大量调用进入到内核的工作负载将观测到很大的性能损失。在一个基准测试中，一个除了调入到内核之外什么都不做的程序，观察到 [它的性能下降大约为 50%][11]；换句话说就是，打补丁后每次对内核的调用的时间要比不打补丁调用内核的时间增加一倍。基准测试使用的 Linux 的网络回环（loopback）也观测到一个很大的影响，比如，在 Postgres 的基准测试中大约是 [17%][12]。真实的数据库负载使用了实时网络可能观测到的影响要低一些，因为使用实时网络时，内核调用的开销基本是使用真实网络的开销。
|
||
|
||
虽然对 Intel 系统的影响是众所周知的，但是它们可能并不是唯一受影响的。其它的一些平台，比如 SPARC 和 IBM 的 S390，是不受这个问题影响的，因为它们的处理器的内存管理并不需要分割地址空间和共享内核页面表；在这些平台上的操作系统一直就是将它们的内核页面表从用户模式中隔离出来的。但是其它的，比如 ARM，可能就没有这么幸运了；[适用于 ARM Linux 的类似补丁][13] 正在开发中。
|
||
|
||
---
|
||
|
||
[][15][PETER BRIGHT][14] 是 Ars 的一位技术编辑。他涉及微软、编程及软件开发、Web 技术和浏览器、以及安全方面。它居住在纽约的布鲁克林。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/
|
||
|
||
作者：[PETER BRIGHT][a]
|
||
译者：[qhwdw](https://github.com/qhwdw)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:https://arstechnica.com/author/peter-bright/
|
||
[1]:https://arstechnica.com/author/peter-bright/
|
||
[2]:https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/?comments=1
|
||
[3]:https://twitter.com/aionescu/status/930412525111296000
|
||
[4]:https://linux.cn/article-9201-1.html
|
||
[5]:https://twitter.com/aionescu/status/948609809540046849
|
||
[6]:https://lkml.org/lkml/2017/12/27/2
|
||
[7]:https://gruss.cc/files/kaiser.pdf
|
||
[8]:https://arstechnica.com/information-technology/2015/08/how-security-flaws-work-the-buffer-overflow/
|
||
[9]:https://github.com/IAIK/KAISER
|
||
[10]:https://twitter.com/brainsmoke/status/948561799875502080
|
||
[11]:https://twitter.com/grsecurity/status/947257569906757638
|
||
[12]:https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3.anarazel.de
|
||
[13]:https://lwn.net/Articles/740393/
|
||
[14]:https://arstechnica.com/author/peter-bright
|
||
[15]:https://arstechnica.com/author/peter-bright
|