长文预警： 这是一个目前严格限制的、禁止披露的安全 bug（LCTT 译注：目前已经部分披露），它影响到目前几乎所有实现虚拟内存的 CPU 架构，需要硬件的改变才能完全解决这个 bug。通过软件来缓解这种影响的紧急开发工作正在进行中，并且最近在 Linux 内核中已经得以实现，并且，在 11 月份，在 NT 内核中也开始了一个类似的紧急开发。在最糟糕的情况下，软件修复会导致一般工作负载出现巨大的减速（LCTT 译注：外在表现为 CPU 性能下降）。这里有一个提示，攻击会影响虚拟化环境，包括 Amazon EC2 和 Google 计算引擎，以及另外的提示是，这种精确的攻击可能涉及一个新的 Rowhammer 变种（LCTT 译注：一个由 Google 安全团队提出的 DRAM 的安全漏洞，在文章的后面部分会简单介绍）。
我一般不太关心安全问题，但是，对于这个 bug 我有点好奇，而一般会去写这个主题的人似乎都很忙，要么就是知道这个主题细节的人会保持沉默。这让我在新年的第一天（元旦那天）花了几个小时深入去挖掘关于这个谜团的更多信息，并且我将这些信息片断拼凑到了一起。
注意，这是一件相互之间高度相关的事件，因此，它的主要描述都是猜测，除非过一段时间，它的限制禁令被取消。我所看到的，包括涉及到的供应商、许多争论和这种戏剧性场面，将在限制禁令取消的那一天出现。
LWN这个事件的线索出现于 12 月 20 日 LWN 上的 内核页面表的当前状况：页面隔离这篇文章。从文章语气上明显可以看到这项工作的紧急程度，内核的核心开发者紧急加入了 KAISER 补丁系列的开发——它由奥地利的 TU Graz 的一组研究人员首次发表于去年 10 月份。
这一系列的补丁的用途从概念上说很简单：为了阻止运行在用户空间的进程在进程页面表中通过映射得到内核空间页面的各种攻击方式，它可以很好地阻止了从非特权的用户空间代码中识别到内核虚拟地址的攻击企图。
这个小组在描述 KAISER 的论文《KASLR 已死：KASLR 永存》摘要中特别指出，当用户代码在 CPU 上处于活动状态的时候，在内存管理硬件中删除所有内核地址空间的信息。
这个补丁集的魅力在于它触及到了核心，内核的全部基柱（以及与用户空间的接口），显然，它应该被最优先考虑。遍观 Linux 中内存管理方面的变化，通常某个变化的首次引入会发生在该改变被合并的很久之前，并且，通常会进行多次的评估、拒绝、以及因各种原因爆发争论的一系列过程。
而 KAISER（就是现在的 KPTI）系列（从引入到）被合并还不足三个月。
ASLR 概述从表面上看，这些补丁设计以确保地址空间布局随机化Address Space Layout Randomization（ASLR）仍然有效：这是一个现代操作系统的安全特性，它试图将更多的随机位引入到公共映射对象的地址空间中。
例如，在引用 /usr/bin/python 时，动态链接将对系统的 C 库、堆、线程栈、以及主要的可执行文件进行排布，去接受随机分配的地址范围：
$ bash-c ‘grep heap /proc/$$/maps’
019de000-01acb000 rw-p 0000000000:000 [heap]
$ bash-c 'grep heap /proc/$$/maps’
023ac000-02499000 rw-p 00000000 00:00 0 [heap]
注意两次运行的 bash 进程的堆（heap）的开始和结束偏移量上的变化。
如果一个缓存区管理的 bug 将导致攻击者可以去覆写一些程序代码指向的内存地址，而那个地址之后将在程序控制流中使用，这样这种攻击者就可以使控制流转向到一个包含他们所选择的内容的缓冲区上。而这个特性的作用是，对于攻击者来说，使用机器代码来填充缓冲区做他们想做的事情（例如，调用 system() C 库函数）将更困难，因为那个函数的地址在不同的运行进程上不同的。