作者：匿名用户
链接：https://www.zhihu.com/question/265012502/answer/288407097
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
首先要明确的是：
1）这个漏洞不是去年说的Intel ME的漏洞；
2）这个漏洞不是很多答主说的依靠时间推测内核加载地址的问题。
这是一个新爆出的漏洞，虽然看起来不是1月2号才暴露出来。因为Linux和Windows早在去年11月份左右就有动作开始修补了。
下面是科普时间：
首先我们需要知道，以前常见的虚拟内存结构怎样的。以32位Linux为例，我们知道2^32 Bytes = 4GB，从应用程序的眼中来看，我拥有4个G的内存。但是，这4个G的内存并不完全属于应用程序——高地址那边的1GB大小的映射是属于内核的。比如，假设内核有一段代码在虚拟地址0xCCCCCCCC这个位置上，应用程序也是无法直接调用的。换句话说，虽然这些地址普通程序不能访问，但内核程序、内核栈等确实映射在这了。
看起来一切正常。接下来，假设我们发现了一个内核漏洞，这个漏洞允许程序调用任意内核级的代码——也就是说，应用程序通过这个漏洞可以调用内核中0xCCCCCCCC地址的程序了，进而对系统造成危害。
那么如何减轻发现内核漏洞之后的危害呢？毕竟，有代码的地方就会有bug。大佬们决定采用一种随机的方法：你不是要调用0xCCCCCCCC这块的代码吗？那我每次启动的时候，把内核映射到一个随机的地址上就好了嘛，比如这段代码这次启动的时候它在0xCCCC0000，下次启动它就变成了0xCCCC8888，让人摸不着头脑。
这种机制就叫KASLR。它随机化内核在虚拟空间中的地址，只有内核自己知道我在哪，别人休想知道。所以说，KASLR不是“修补”漏洞，而是提高了利用漏洞的成本——最好的情况是，虽然有人发现了漏洞，但却难以利用。
但是，魔高一尺道高一丈。另一位大佬说，你这太弱了。我用一种方法，能探测出你究竟随机到哪去了。这就是很多答主说的Time Based Attack。因为放代码的地址和没放代码的地址，在某些操作下时间长短不一样。
因此，这种Attack不是真正的漏洞攻击，但他让KASLR机制失效了。如果有人发现了可利用的内核漏洞后，就可以用这种方式绕过KASLR。
大佬还说了，虽然KASLR不好使了，但我的新方法好使啊。这个新方法就是KAISER——内核除了让应用程序知道必要的信息外，不再在应用程序的眼中“可见”。但是代价也是有的，就是性能会有所下降。
好了，下面到了今天主角登场的时间了。这次的CPU漏洞，能够使得应用程序访问任意地址——包括映射到应用程序空间中的内核地址（即新闻标题中的“Kernel Memory Leaking”，内核内存泄露）。这就相当于我们刚才说的“内核漏洞”（虽然这是CPU的bug），但是这个漏洞可不好修。所以只能阻止这个漏洞的利用条件了——用KAISER机制，让你根本访问不到内核中的东西，把内核从应用程序的眼中“隐藏”。虽然降低了一些性能，但也总比被搞事情强。
Ps. 根据一些文章，目前这项机制在Linux中改名为了“KPTI”，即内核页表隔离。
非商业转载一部分内容
新能损失部分
目前phoronix已对此进行了测试，IO性能几乎下降了50%，编译性能下降了接近30%，postgresql和redis也有差不多20%的性能下跌，详细地址：Initial Benchmarks Of The Performance Impact Resulting From Linux's x86 Security Changes
作者：Allen Leung
链接：https://www.zhihu.com/question/265012502/answer/288199200
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
原文地址：https://www.cnblogs.com/jinanxiaolaohu/p/8185696.html