Intel处理器爆出重大安全漏洞

用英特尔处理器的产品有了大麻烦!几乎所有过去10年中生产的英特尔( INTC-US )处理器被发现有个重要的安全漏洞，可以允许「普通用户只需启动某些程序，或透过Web浏览器中的JavaScript，就能在某种程度上辨识原应受保护的内核记忆体内的内容」，《Register》周二报导了这项发现。

从本质上讲，当代英特尔处理器有一个设计缺陷，可能允许恶意程序读取设备内核记忆体受保护的区域，这块区域专门用于保护操作系统最重要的核心组件以及与系统硬件交动的内存记忆体。这个漏洞可能会暴露受保护的信息，像是密码。

那就意味着程序可以无视权限控制，随意读取本程序虚拟内存内的数据，由于Linux和Windows的内存模型设计(内核与程序共享一个虚拟地址空间，通过权限控制阻止程序访问内核)，这意味着任何程序都可以读取内核，包括诸如加密文件系统的密钥之类的数据。

由于这个漏洞是被嵌入Intel x86-64韧体里，因此需要用操作系统等级的覆写才能改正，这些主要的操作系统包括Windows、Linux和macOS。

在这个问题被发现后，开发者急于在接下来的几周内修补系统，所以这个设计缺陷的确切细节以及用户容易受到攻击的程度现在依然在保密状态，但情况可能非常糟。在最坏的情况下，像在网页或云端托管的恶意软件上启动JavaScript 那样简单的事情，都可能刺探以Intel 设备为主干最敏感的内部工作。

由于修复需要将内核记忆体完全从用户操作流程中分离出来，修补后的操作系统可能会出现「5% 到30% 的运作迟缓，程度取决于工作和处理器型号」。

5% 到30% 是一个令人惊吓的数字，但由于现在一切都仍在保密中，很难判定它们对消费者的影响究竟有多明显，不过可能对企业级的云端计算系统可能是冲击最大的。对于普通用户而言，影响可能可以被忽略不计，只要未来的修复版本能实现解决方案，就可能降低冲击。

《Gizmodo》网站引述《Python Sweetness》博客指出，「解决软件的紧急开发已公开化，近日将在Linux 内核中试行」，「而在11 月类似的解决措施也开始出现在NT 内核中。」「在最糟的情况下，软件修复会导致基本工作负载的大幅降速...... 许多线索都显示这会影响到常见的虚拟化环境，包括Amazon EC2 和Google Compute Engine。」

《Gizmodo》网站报导，整件事唯一让人欣慰的是，即使这个漏洞埋得如此之深，得花上10 年的时间才能找到它，但发现者并没有隐而不谈。而唯一的获利者可能是市占率极小的AMD 处理器，它大概会在一旁偷笑。

英特尔股价周三下跌3.5% 至45.22 美元，Advanced Micro Devices(AMD) 股价则上涨。

根据the Register 网站的一份报告指出，Linux 与微软的视窗作业系统若使用英特尔芯片，速度将减慢5% 至30%。

该报告并指出，AMD 芯片不会受到影响。AMD 股价上涨7.2% 至11.77 美元。

关于此漏洞的相关评价

知乎用户Allen Leung表示，此漏洞会导致低权限应用访问到内核内存;此漏洞是硬件设计导致的，无法使用microcode修复，只能进行OS级的修复;OS级的修复会导致严重的性能问题，将会导致5%-30%的性能下降。

他进一步指出，目前phoronix已对此进行了测试，IO性能几乎下降了50%，编译性能下降了接近30%，postgresql和redis也有差不多20%的性能下跌。

用户鱼羊鲜则指出，此漏洞最早由某404公司研究机构发现,目前还不清楚有没有人利用。

早在17年中就被发现了,各大芯片和OS厂互相通气一起研究办法 因为底层的硬件的设计漏洞 很难修复了 只能靠os方面打补丁，突破口就是speculative execution , 用的某种side channel attack.发现者估计也是硬件+架构+os大牛了...总之能获取内核的数据 。

speculative execution算是很普遍的优化方式,基本现代复杂一点的核都会用到,intel 就更不用说了. 修复完加上限制后会有较大的影响. 但具体怎样无从得知。

至于修复方式，知乎用户楼群指出了以下几点：

1)芯片微码更新不足以修复漏洞，必须修改系统或者购买新设计的 CPU

2)目前 Linux 内核的解决方案是重新设计页表(KPTI 技术，前身为 KAISER)。之前普通程序和内核程序共用页表，靠 CPU 来阻止普通程序的越权访问。新方案让内核使用另外一个页表，而普通程序的页表中只保留一些必要的内核信息(例如调用内核的地址)。这个方案会导致每次普通程序和内核程序之间的切换(例如系统内核调用或者硬件中断)都需要切换页表，引起 CPU 的 TLB 缓存刷新。TLB 缓存刷新相对来说是非常耗时的，因此会降低系统的效率。

3)KAISER 技术对系统性能的影响一般是 5%，最高可达 30%。一些高级的芯片功能(例如 PCID)可以支持其他技术，从而减少性能影响。Linux 已经在 4.14 版本的开发过程中添加了对 PCID 的支持。

4)在 Linux 系统中，KPTI 只有在英特尔芯片上才会启用，因此 AMD 芯片不受影响，且用户可以通过手动修改开关的方式关闭 KPTI

英特尔称其他公司芯片也存在问题 正与AMD、ARM合作

据CNBC北京时间1月4日报道，英特尔当地时间星期三表示，正在与AMD、ARM和软件厂商合作，解决媒体报道的一个安全问题。英特尔称，媒体有关安全问题是由缺陷造成的，以及只有其产品存在相关安全问题的报道是不准确的，其他公司的芯片也存在相同问题。

此前，the Register刊文称，修正英特尔芯片中一处严重安全缺陷的补丁软件会影响到芯片性能。由于这一报道在市场上产生广泛影响，今天常规交易中，英特尔股价一度下跌6%，AMD股价则一度上涨逾8%。媒体报道称AMD芯片不会受到这一问题影响。

英特尔表示，其他公司芯片也存在相同问题。英特尔在一份声明中说，“最近媒体报道称这一安全问题是由一处‘缺陷’引起的，而且只影响英特尔芯片的说法是不正确的。根据目前的分析，许多类型的计算设备——配置多家不同公司处理器、运行不同操作系统——也会受到这些安全问题的影响。”

声明称，英特尔的计划是“迅速和建设性”地解决这一问题。

据the Register称，除影响PC外，该安全问题还影响公共云服务提供商，例如亚马逊Web Services、微软Azure和谷歌Cloud Platform。它们使用户能租借英特尔芯片，在Windows和Linux上运行自己的应用。

据测试过Linux版补丁软件的Phoronix高管迈克尔·拉拉贝尔(Michael Larabel)指出，补丁软件会使系统性能“下降1至2位数”。在PC上运行游戏的性能似乎不受补丁软件影响，运行PostgreSQL和Redis等数据库的性能会有适度下降。

英特尔在声明中也提到了性能问题，“与部分媒体报道截然不同的是，任何性能下降都取决于负载，对于普通用户而言，性能下降并不严重，随着时间推移，对性能的影响将得到缓解。”

英特尔称，它计划下周讨论这一安全问题，“届时会有更多软件和固件更新包发布”。

这一事件会给英特尔带来费用甚至诉讼，市场研究公司Bernstein分析师斯塔西·拉斯冈(Stacy Rasgon)在星期三发表的报告中也提及了这一点。

AppleInsider刊文称，苹果一直在忙于修正影响macOS的漏洞;the Register刊文称，微软已经在对修正该问题的Windows更新包进行测试。

谷歌、亚马逊、苹果和微软未就此置评。

英特尔建议用户，“与操作系统开发商或系统制造商接洽，尽可能快地安装它们发布的补丁软件。”

附：基本知识科普

首先，我们需要了解一下现在的CPU的基本工作方式：

指令解码：

将指令翻译成微代码(是，x86处理器基本上都已经是硬件级JIT引擎了……)

将微代码丢进执行队列

调度执行：

调度器检查队列中的微代码，依据现有资源和微代码间的依赖关系，选出可以执行的微代码

调度器将这些微代码(可能有多个)发送给相应的执行器执行

执行器将执行结果丢回调度器(结果、异常、状态位之类的)

调度器检查缓存里最旧的指令的微代码是否已经全部执行完毕，如果没有完成执行，回到第2.1步

将最旧的指令的微代码移出队列

结果提交：

按指令的执行结果更新架构状态(写入寄存器、产生中断等)

如果发生了需要特殊操作的事件(比如异常、中断等)，清空整个流水线并按流程处理

注意除了3可以清空掉1、2之外，这三块基本上是互相独立工作的

如果我们访问了不能访问的内存，这个异常是在3.2这一步里引发的，此时整个流水线都会被清空

但!是!2.2这一步可能已经访问了这部分内存，只是因为3.2引发异常而丢弃了结果

所以说如果有办法能观测到2这一块对内存的使用情况的话……

比如这段汇编：

CLFLUSH [用户地址]

CLFLUSH [用户地址 + 1]

MOV AX, [内核地址]

AND AX, 1

MOV BL, [用户地址 + AX]

显然，在第3条就会发生异常。

但是，万一，万一在清空流水线前，调度执行阶段执行到了第5条会怎么样!

如果这个内核地址的最低位是0，那么我们会访问用户地址 ，但是如果是1的话，我们会访问用户地址+1

如果我们把这个地址放在缓存页的边界上 ，那么根据这个内核地址上最低位值的不同，被加载进缓存的页也会不同，后续访问两个页的延迟会存在区别

所以说……我们就能推断这个内核地址上的值了?

哦对，以上这段是确认不能用了我才发出来的(真要能用早三五年就被人报了好么)

估计这次的东西可能是类似的原因，调度执行阶段会忽略访问控制，以致在后续执行中可以通过其他间接方式观测/推测这个不可访问的值。

其次我们需要知道，以前常见的虚拟内存结构怎样的。

以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——内核除了让应用程序知道必要的信息外，不再在应用程序的眼中“可见”。但是代价也是有的，就是性能会有所下降。