这是一个简单的示例，ASLR 被设计用于去保护类似这样的许多场景，包括阻止攻击者了解有可能被用来修改控制流的程序数据的地址或者实现一个攻击。
KASLR 是应用到内核本身的一个 “简化的” ASLR：在每个重新引导的系统上，属于内核的地址范围是随机的，这样就使得，虽然被攻击者操控的控制流运行在内核模式上，但是，他们不能猜测到为实现他们的攻击目的所需要的函数和结构的地址，比如，定位当前进程的数据段，将活动的 UID 从一个非特权用户提升到 root 用户，等等。
坏消息：缓减这种攻击的软件运行成本过于贵重之前的方式，Linux 将内核的内存映射到用户内存的同一个页面表中的主要原因是，当用户的代码触发一个系统调用、故障、或者产生中断时，就不需要改变正在运行的进程的虚拟内存布局。
因为它不需要去改变虚拟内存布局，进而也就不需要去清洗掉（flush）依赖于该布局的与 CPU 性能高度相关的缓存（LCTT 译注：意即如果清掉这些高速缓存，CPU 性能就会下降），而主要是通过 转换查找缓冲器Translation Lookaside Buffer（TLB）（LCTT 译注：TLB ，将虚拟地址转换为物理地址）。
随着页面表分割补丁的合并，内核每次开始运行时，需要将内核的缓存清掉，并且，每次用户代码恢复运行时都会这样。对于大多数工作负载，在每个系统调用中，TLB 的实际总损失将导致明显的变慢：@grsecurity 测量的一个简单的案例，在一个最新的 AMD CPU 上，Linux du -s 命令变慢了 50%。
34C3在今年的 CCC 大会上，你可以找到 TU Graz 的另外一位研究人员，《描述了一个纯 Javascript 的 ASLR 攻击》，通过仔细地掌握 CPU 内存管理单元的操作时机，遍历了描述虚拟内存布局的页面表，来实现 ASLR 攻击。它通过高度精确的时间掌握和选择性回收的 CPU 缓存行的组合方式来实现这种结果，一个运行在 web 浏览器的 Javascript 程序可以找回一个 Javascript 对象的虚拟地址，使得可以利用浏览器内存管理 bug 进行接下来的攻击。（LCTT 译注：本文作者勘误说，上述链接 CCC 的讲演与 KAISER 补丁完全无关，是作者弄错了）
因此，从表面上看，我们有一组 KAISER 补丁，也展示了解除 ASLR 化地址的技术，并且，这个展示使用的是 Javascript，它很快就可以在一个操作系统内核上进行重新部署。
虚拟内存概述在通常情况下，当一些机器码尝试去加载、存储、或者跳转到一个内存地址时，现代的 CPU 必须首先去转换这个 虚拟地址 到一个 物理地址 ，这是通过遍历一系列操作系统托管的数组（被称为页面表）的方式进行的，这些数组描述了虚拟地址和安装在这台机器上的物理内存之间的映射。
在现代操作系统中，虚拟内存可能是最重要的强大特性：它可以避免什么发生呢？例如，一个濒临死亡的进程崩溃了操作系统、一个 web 浏览器 bug 崩溃了你的桌面环境、或者一个运行在 Amazon EC2 中的虚拟机的变化影响了同一台主机上的另一个虚拟机。
这种攻击的原理是，利用 CPU 上维护的大量的缓存，通过仔细地操纵这些缓存的内容，它可以去推测内存管理单元的地址，以去访问页面表的不同层级，因为一个未缓存的访问将比一个缓存的访问花费更长的时间（以实时而言）。通过检测页面表上可访问的元素，它可能能够恢复在 MMU（LCTT 译注：存储器管理单元）忙于解决的虚拟地址中的大部分比特（bits）。
这种动机的证据，但是不用恐慌我们找到了动机，但是到目前为止，我们并没有看到这项工作引进任何恐慌。总的来说，ASLR 并不能完全缓减这种风险，并且也是一道最后的防线：仅在这 6 个月的周期内，即便是一个没有安全意识的人也能看到一些关于解除（unmasking） ASLR 化的指针的新闻，并且，实际上这种事从 ASLR 出现时就有了。
单独的修复 ASLR 并不足于去描述这项工作高优先级背后的动机。
它是硬件安全 bug 的证据通过阅读这一系列补丁，可以明确许多事情。
第一，正如 @grsecurity 指出 的，代码中的一些注释已经被编辑掉了（redacted），并且，描述这项工作的附加的主文档文件已经在 Linux 源代码树中看不到了。