关于intel cpu芯片级（硬件设计上的）漏洞可能导致内核内存泄露（kernal memory leaking)的思考

（这是一个测试博客效果的文章，内容是自己一月初写的） 

      昨天看公众号发现了一个还算挺爆炸性的新闻：intel cpu芯片级（硬件设计上的）漏洞可能导致内核内存泄露（kernal memory leaking)。

        看了一些网上的解读，结合之前ics cse学到的知识，思考了漏洞的前因后果，自己也设想了下攻击方法，结果一看有大佬跟我想法差不多，觉得挺有成就感，特来分享下，顺便解释下漏洞是怎么回事。
        我们知道，计算机上运行了两种程序，操作系统（内核）和你的程序。这两种程序的权限不同，这是为了保护计算机。实际上我们的程序在运行时，经常需要一些较高权限的系统调用操作（写磁盘，读磁盘），这时候需要运行操作系统内核的代码，因为这种操作非常多，为了性能上的考虑，windows和linux使用的x86架构中，将包括以上代码的内核和程序放在了一起，准确的说是他们使用一个虚拟内存空间（32位下大小是4GB），因此程序和内核代码的距离减少了，在一个32位地址空间中他们可以任意的访问对方的代码或数据。
        当然实际上这是不可能的，因为权限的设定，内核代码当然不能被程序随便访问，不然被坏程序控制了操作系统就不妙了。因此，防止程序访问内核代码的工作交给了cpu，cpu在运行每一条指令时，会检查这条指令是不是访问了内核代码所在地址，起到保护作用。
intel的cpu 是流水线设计，实际上大家都这么设计，因为每条指令执行时间可能很慢，不可能等到它结束了再执行下一条，因此，没等到前一个执行完，下一个就开始执行，这就是流水化。这就带来一个问题，如果下一条指令和前一个有关系呢（它跟前一个执行结果相关），解决方案就是，猜，猜前一条的结果。然而，前一条出结果发现，猜错了，那就必须把下一条清空了，重新来一遍。
        和前面的权限检查结合起来，当发现当前指令是非法指令时，就应该停下来报错，停止后续指令执行。然而这次漏洞的关键是：当检查出问题时，后面的指令可能已经做了很多工作了。换句话说，发现程序非法访问内核代码时，程序的后续工作已经展开，而且很可能跟这条非法指令相关。

        （今日补充：可能非法指令的相关信息写入了cache，但分支预测错误并没有把cache清掉）
        我的设想是：程序利用非法获取的内核地址值，去加载不同的合法的位于页面边缘的普通地址，根据是否缺页反应出的时间差异（非常明显，毫秒级），推测内核的代码和数据，获得关键信息。（当然，这种攻击是老套路了）
怎样避免：很暴力简单，将内核的信息放到不同地方，不和程序放在一起，这样内核地址和程序地址根本不在同一空间。这种方法叫 KPTI，很早之前就做出来了，只不过微软（linux)一直没采用。因为这东西太费劲，每次程序系统调用（读写磁盘）都要把当前控制流完全切换到内核去，不像以前，近在眼前。