迅维网

标题: 如何看待 2018 年 1 月 2 日爆出的 Intel CPU 设计漏洞？ [打印本页]

作者: wason1 时间: 2018-1-5 11:18
标题: 如何看待 2018 年 1 月 2 日爆出的 Intel CPU 设计漏洞？
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

作者: lkamxmk 时间: 2018-1-5 11:18
目前已知的消息（我不完全确定是这样）

此漏洞会导致低权限应用访问到内核内存
此漏洞是硬件设计导致的，无法使用microcode修复，只能进行OS级的修复
OS级的修复会导致严重的性能问题，将会导致5%-30%的性能下降
目前phoronix已对此进行了测试，IO性能几乎下降了50%，编译性能下降了接近30%，postgresql和redis也有差不多20%的性能下跌，详细地址：

Initial Benchmarks Of The Performance Impact Resulting From Linux&amp;amp;#x27;s x86 Security Changes

AMD不受此漏洞影响

Report: Intel CPUs suffer from major security flaw, fix could bring notable performance hit to macOS-- 英文版的详细信息
Intel: Details und Benchmarks zur Sicherheitslücke in allen CPUs-- 最早的新闻来源

@vczh 顺便让轮子哥来作答………………
===========================
2018年1月4日的更新：
根据某发行版Linux的内核组基友的说明，目前推测的性能影响大部分可以取5%的下限，影响最大的是IO频繁的应用环境，所以最大的影响应该是各大公司的数据库服务器。
===========================
继续更新：
这一次由Intel服务器CPU产品诱发的安全事故现在规模正式扩大，确认波及到ARM和AMD，也就是说，近二十年来生产的几乎一切手机、电脑、云计算产品都在风险之列。
安全人员将两个新的漏洞命名为Meltdown（熔断）和Spectre（幽灵），前者允许低权限、用户级别的应用程序“越界”访问系统级的内存，从而造成数据泄露。

听说是由Google Zero团队发现的，目前这个规模就真的很大了……
Spectre affects Intel, AMD, and ARM processors, broadening its reach to include mobile phones, embedded devices, and pretty much anything with a chip in it. Which, of course, is everything from thermostats to baby monitors now.
It works differently from Meltdown; Spectre essentially tricks applications into accidentally disclosing information that would normally be inaccessible, safe inside their protected memory area. This is a trickier one to pull off, but because it’s based on an established practice in multiple chip architectures, it’s going to be even trickier to fix.

主要麻烦的是幽灵这个漏洞………………影响全部CPU………………不单止可以从内核态泄露，虚拟化的也可以………………而且目前没有有效的可行性修复方法………………
参考新闻来源：
Kernel panic! What are Meltdown and Spectre, the bugs affecting nearly every computer and device?“Meltdown” and “Spectre”: Every modern processor has unfixable security flaws有新消息会继续更新。
===================================
from Google Zero：
Testing also showed that an attack running on one virtual machine was able to access the physical memory of the host machine, and through that, gain read-access to the memory of a different virtual machine on the same host.
These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running on them.
There is no single fix for all three attack variants; each requires protection independently. Many vendors have patches available for one or more of these attacks.
We will continue our work to mitigate these vulnerabilities and will update both our product support page and this blog post as we release further fixes. More broadly, we appreciate the support and involvement of all the partners and Google engineers who worked tirelessly over the last few months to make our users and customers safe.
==================================
贴一下目前最终的结论
Google Project Zero 和奥地利格拉茨技术大学等机构的研究人员正式披露了三个处理器高危漏洞，分别编号为 CVE-2017-5753（Variant 1）、CVE-2017-5715（Variant 2）和 CVE-2017-5754（Variant 3），前两个漏洞被称为 Spectre，后一个漏洞被称为 Meltdown，Spectre Variant 1 影响 AMD，英特尔和 ARM 处理器，而所有三个漏洞都影响英特尔处理器，研究人员已经开发出了概念验证的漏洞利用。AMD 和 ARM 已经发表声明称漏洞可以通过软件修正，对性能影响不大。而英特尔处理器的软件修正则被认为存在显著的性能影响。
目前具体的实例演示是这样的：

总结一下，最后是AMD和ARM都受到Spectre V1影响，就是上边说的全CPU受影响的漏洞，这个漏洞不是硬件级的所以可以比较容易处理，最终AMD和ARM可以通过系统更新来填补漏洞而且不会对性能有重大影响。而Intel目前受到所有三个漏洞影响，最终如何解决不明。
来源：
处理器漏洞 Meltdown 和 Spectre

作者: dsadsadsasd 时间: 2018-1-5 11:18
// 我不是相关从业人员，也不是幕后人士，回答仅供参考
首先要明确的是：
1）这个漏洞不是去年说的Intel ME的漏洞；
2）这个漏洞不是很多答主说的依靠时间推测内核加载地址的问题。（Update：Meltdown的利用方法同样依靠计时，但可以推测出内存内容）
这是一个新爆出的漏洞，虽然看起来不是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漏洞，能够使得应用程序访问任意虚拟地址（更正：Meltdown可以读取任意物理内存）——包括映射到应用程序空间中的内核内存（即新闻标题中的“Kernel Memory Leaking”，内核内存泄露）。这就相当于我们刚才说的“内核漏洞”（虽然这是CPU的bug），但是这个漏洞可不好修。所以只能阻止这个漏洞的利用条件了——用KAISER机制，让你根本访问不到内核中的东西，把内核从应用程序的眼中“隐藏”。虽然降低了一些性能，但也总比被搞事情强。
Ps. 根据一些文章，目前这项机制在Linux中改名为了“KPTI”，即内核页表隔离。

作者: ylzhang 时间: 2018-1-5 11:18
再次更新：Google Project Zero 今天发布这篇文章，基本可以确定文章描述的就是这次引发讨论的漏洞。文章中描述了 Spectre 和 Meltdown 两种攻击方式，都是利用之前被怀疑的“预测执行”机制实现的，且这两种方法需要用不同的方式来分别防御。

我现在只读了 Meltdown 那篇文章，梗概大概是这样的：

Meltdown 技术可以读取 Linux、Mac OS 的整个物理内存和 Windows 的大部分物理内存。Linux 内核 2.6.32 ~ 4.13.0 的版本以及最新的 Windows 10 均受到影响。
可以读取其他进程的物理内存。即使在使用内核共享技术（例如 Docker, LXC）或者用 Xen 芯片的 paravirtualization 功能制作的沙箱中，也可以读取内核或 hypervisor 内存。
影响了大部分从 2010 年开始生产的 Intel 芯片。在 ARM 和 AMD 芯片上的实验没有成功。
漏洞根本原因是“预测执行”技术的设计缺陷。
实验中破译数据的速度可达 503 KB/s，错误率低至万分之二。实验中已经可以读取 Firefox 56 的内存，并从中找到网页请求的头数据和浏览器储存的密码。
KAISER 技术可以阻止 Meltdown。目前 Windows Build 17035, Linux Kernel 4.15, OS X 10.13.2 和 iOS 均添加了 KAISER 技术或其变种。

Meltdown 的过程大概是：

构造一段代码，使得一句需要访问受保护内存的指令本来永远无法达到，但是可能因为“预测执行”而提前执行。
那句提前执行的代码会根据受保护的数据内容不同而访问内存中的不同位置（例如如果 data 是想破译的数据，那么 prob_array[data*4096] 会根据 data 的不同而访问不同的内存页）。
芯片发现权限不足，因此回滚之前的操作，将状态恢复到那条指令执行之前的情况。然而，CPU 中的内存缓存没有回滚。
攻击程序检测 prob_array 中的每个内存页取回数据的时间。如果某内存页的取回时间很短，说明该页在缓存中，是之前刚刚访问过的页面。从这个页面的下标就可以推断出 data 是什么。

以下是原答案：

更新：根据 @冯博群提供的链接修正了一些原文中描述比较模糊的细节。

帮大家翻译一下文章梗概：

英特尔的芯片级设计漏洞导致 Linux 和 Windows 内核的关键部分必须重新设计

======= 关于修复进展 =======

开源程序员们已经修改了 Linux 的虚拟内存系统，但是代码注释被缩减，人们猜测是为了隐藏漏洞的详细信息。
Windows 预计在本周四正式发布相关补丁，且补丁已经在去年十一月、十二月的 Windows Insider 版本中发布给了测试用户。
macOS 也需要进行升级。

======= 关于修复方法 =======

芯片微码更新不足以修复漏洞，必须修改系统或者购买新设计的 CPU。
目前 Linux 内核的解决方案是重新设计页表（KPTI 技术，前身为 KAISER）。之前普通程序和内核程序共用页表，靠 CPU 来阻止普通程序的越权访问。新方案让内核使用另外一个页表，而普通程序的页表中只保留一些必要的内核信息（例如调用内核的地址）。这个方案会导致每次普通程序和内核程序之间的切换（例如系统内核调用或者硬件中断）都需要切换页表，引起 CPU 的 TLB 缓存刷新。TLB 缓存刷新相对来说是非常耗时的，因此会降低系统的效率。
KAISER 技术对系统性能的影响一般是 5%，最高可达 30%。一些高级的芯片功能（例如 PCID）可以支持其他技术，从而减少性能影响。Linux 已经在 4.14 版本的开发过程中添加了对 PCID 的支持。
在 Linux 系统中，KPTI 只有在英特尔芯片上才会启用，因此 AMD 芯片不受影响，且用户可以通过手动修改开关的方式关闭 KPTI 。

======= 关于漏洞影响 =======

根据 AMD 在 Linux 内核邮件列表里发送的邮件，AMD 芯片没有发现这样的漏洞。
人们推测，漏洞会导致普通程序可以获得受保护的内核页表信息，进而导致一些内核保护技术（例如 KASLR，即内核地址空间布局随机化）可能被攻破。
微软 Azure 云服务将在 1 月 10 日进行维护并重启，人们推测可能是为了修复这个漏洞。
Amazon Web Services 通过邮件警告客户，本周五会有一次重要的安全更新。

======= 其他信息 =======

还是根据 AMD 的那封邮件，人们推测出现问题的根源是“预测执行”（Speculative execution）机制。这个技术让 CPU 可以预测即将执行的代码，从而加快运行速度。人们猜测，可能芯片在完成权限检查之前，就会因为这个机制而执行本来不该执行的代码。
也有人推测这个漏洞就是去年年末传言的虚拟机器监视器（hypervisor ）的重大 bug。
KPTI 的前身 KAISER 本来是用来预防 time-based attack 的，但是因为性能损失较高而一直没有并入主流 Linux 版本中。
Linux 内核中阻止 KPTI 在 AMD 芯片上自动启用的代码是 AMD 自己提交的。

作者: wyo315 时间: 2018-1-5 11:18
话说知乎那么多 Insider，17035 以上版本都有针对 Spectre/Meltdown 的 patch（那组修改几乎把整个内核翻了个底朝天），也没见你们说电脑变卡的。大多数现代 CPU 都有 PCID，基本消除了性能影响。
（不过我相当怀疑你更新完了发现腾讯的游戏玩不了了……）
国外好事者的跑分数据：
https://youtu.be/_qZksorJAuY可以看出这个 patch 对于运算性能没有影响，对 IO 性能有影响，但是远没有 30% 那么剧烈。

AS SSD Benchmark

ATTO Disk Benchmark

Cinebench R15

Corona 1.3 Benchmark

Excel 2016 蒙特卡洛模拟

7z 压缩解压

游戏

作者: oLjwRgTm 时间: 2018-1-5 11:18
我目前收集到的最新消息。

关于漏洞：
这次的漏洞一共有三个variant，在Google Project Zero发公告前，有一篇关于KAISER的论文(就是之前很多答主都引用过的作者有Daniel Gruss那篇)将其中variant 1和2命名为Spectre，3命名为Meltdown[1]。
在这其中，Spectre对所有的AMD，Intel和ARM处理器都有效。

// 但是，由于Spectre的攻击不存在越权读取内存的情况，所以user mode的进程无法获得kernel mode进程的信息，只会导致进程间的内存泄漏。这个漏洞只能由各个应用和软件自行修复，不需要OS级的补救。

【之前写的这一段是错的，更正如下】
Spectre的variant 1能读取同一用户态进程中分支预测mis掉、本应该被清理的那部分内存，不涉及越权读取。在1的基础上更进一步的利用这个漏洞，可以针对运行现在流通的发行版Linux内核的电脑，在i系列cpu上一次读取4Gb的内核虚拟内存，速度约为2000字节每秒。每次攻击需要4秒启动时间。在Linux开了BPF JIT后(这一项在Linux中是默认关闭的)也可以在amd的cpu上进行一样的操作。
Spectre的variant 2 可以利用一个已经过时的Debian内核，让一个内核虚拟内存的guest进程运行在root权限下可以读host内核内存。读取速度约为1500字节每秒，并有可优化的空间。每次攻击在一个有64G内存的电脑上需要10-30分钟的准备时间，这个时间理论上跟内存大小成正比[2]。
我发表一点bia言，2000字节每秒的速度真的很慢很慢，要想搜完1个G的内存都需要接近6天。个人认为Spectre很可能没有太大的利用价值，这也可能是现在没有多少针对Spectre的补丁的原因。希望有大神来打脸。
现在在大规模讨论的漏洞其实是Meltdown，这个漏洞会导致越权读取内存的情况，会导致kernel mode进程的内存泄漏。Linux和Windows所植入的KPTI及类似的内存管理方法只针对Meltdown有效[3]。
目前Google Project Zero测试过的CPU包括Intel的i系列构架，AMD Zen之前的构架，以及ARM Cortex-A57的ARM64构架。其中Meltdown只影响i系列，Spectre会影响ARM64，i和挖掘机。
关于Meltdown的修复：
Linux和Windows的详情之前的答主都已经说过了，Linux已经发布patch后的内核，Windows 10很快就会推送打好补丁的正式版。
三大云服务运营商AWS，Azure，GAE都会在近期停机打补丁。
macOS目前确认在上个月6号发布的macOS High Sierra 10.13.2、2017-002 Sierra和2017-005 El Capitan中就已经修复了这个漏洞[4]。这些补丁有可能也将Spectre修复了，详情见Ref的链接中第一项Apache。macOS引入的功能被称为Double Mapping，从名称推测跟KAISER是一个类似的机制[5]。顺便多说一句，爆料者说10.13.3会有惊喜。
关于修复漏洞造成的性能影响：
目前很多消息报告说对性能有5%-30%甚至是50%I/O性能的巨大影响。但是实际上影响会小很多。当OS引入类似于KAISER的内存管理后，如果CPU支持PCID那么性能几乎不受影响。Intel在消费级市场是从93年开始引入PCID的，从Haswell构架开始有针对PCID进行优化。PCID本身已经有20多年的历史了，UN*X内核对PCID的支持已经很完善了（评论里的朋友消息：Linux并没有起用PCID），而且Darwin核心很早就开始使用PCID了。所以在i3/5/7-4xxx以及之后的Mac用户可以放心，Windows应该也已经启用了PCID，官网上有提到新一些的硬件受影响会较小。理论上讲I/O的性能也会因为有PCID不会下降50%这么多[6]。
Ref.
[1] Google Project Zero Blog
[2] Reply from user ramrod from Phoronix
[3] Google Project Zero Blog
[4] macOS High Sierra 10.13.2, Security Update 2017-002 Sierra, and Security Update 2017-005 El Capitan
[5] The question on everyone‘s mind: Does MacOS fix the Intel #KPTI issue?
[6] Alex Ionescu

作者: zhaobai 时间: 2018-1-5 11:18
从原理和起因角度，大家已经分析的差不多了，不少人最关心的，应该是这次漏洞到底对我们这些普通用户有什么影响。
首先说结论，我目前没看出什么性能损失（游戏，建模（3dmax，cad），Adobe全家桶，安卓模拟器，SATA，pcie性能都正常）。估计90%以上的人是不会受影响的，如果你需要工作都在上面几项之内，你可以放心的更新补丁，不会损失掉任何性能。

首先看看游戏性能，这是基于linux的测试，所以游戏数量有限...但是影响不大，不光的图上的两款。Dota2，地铁这些游戏影响也很小。
那么渲染呢？
x264没问题

adobe全家桶问题都不大。

office软件..

文件解压...

Windows下的刺客信条起源...

ssd性能，差距理解为误差都毫无问题，有的项目在打了补丁之后分数甚至提高了，只能说明这个补丁对该项测试性能的影响是不存在的。
要虚拟机的用户应该会受到较大的影响。
但是如果只是游戏，办公，视频剪辑，建模这些简单工作，影响还是不大的。
今天更新了kb4056892这个补丁。然后跑了一下内存和缓存性能。

这是更新前

这是更新后
更新后还变快了一点点....大概是误差吧...io性能表现最突出就是内存和缓存性能了，这都没有影响，日常使用看来是毫无影响了，特定程序性能也许会严重下降吧...

这次漏洞的最大受害者是数据中心，咱们倒不算啥受害者，然而数据中心是Intel大单生意的主要来源，这次损失可惨重了。

作者: xiexueqiao 时间: 2018-1-5 11:18
首先感谢知乎朋友的邀请，我想先用一个容易理解的比喻来说明Intel CPU最近的Meltdown Bug：
假定你希望知道你老板最近是不是在北京，但是按照公司规定，你是无法知道老板行踪的。所以你决定尝试窃取这个秘密。
于是，你给老板的秘书打电话说“你能不能帮我查下老板的日程，看看老板是不是在北京出差，如果在北京的话，再帮我去公司CRM系统里面查下，看看我名下近期需要拜访的北京重点客户，这些可能是需要老板帮忙拜访的。”
秘书很敬业，先是查了老板的日程，发现老板确实在北京；然后又花了几分钟时间从CRM系统里把近期需要拜访的北京重点客户名单拿出来。这时，她突然反应过来你是不应该知道老板现在在哪里的。于是她回电话告诉你“不好意思，我觉得你不应该了解老板去了哪里。”
你回复道：“那好吧，那麻烦你直接告诉我有哪些北京重点客户是近期需要拜访的？”
因为秘书刚刚已经从系统里查到了对应的客户，并且你有权限了解这些，她很快就回答你：“近期需要拜访的北京重点客户有A,B,C.......”
通常情况下，从系统里面调取出这些信息需要好几分钟，但是秘书很快就告诉了你答案，那么你可以推测老板就在北京。所以，秘密就这样泄露了。
CPU执行的过程，有一个很重要的加速优化技术叫做“speculative execution", 其实就和以上比喻中秘书的工作方式一样，她只有在告诉你结果的时候，才发现你不应该了解这个信息。但是此时，通过下一步执行结果的速度变化，仍然有可能暴露重要的信息，这就是所谓的"time based side channel attack（基于时间的旁路攻击）”。
Intel的CPU在服务器市场可能占据了99%的份额，一旦它出了问题，就意味着有很多服务器上的敏感数据都可能泄露。因此这是一次非常严重的安全事故，有可能比Heartbleed更严重。

作者: jansie1314 时间: 2018-1-5 11:18
大家都在回答漏洞的原理，对此我也无法完全解释清楚，但不说一些感觉不太好，我今天上午将7700HQ做了更新补丁前后的一些测试，包括使用sisoftware 2017的内存事务性测试，.net公共虚拟机语言环境的算术和SIMD测试（广义虚拟机下的计算测试），内存与缓存带宽测试和在Android studio上使用虚拟设备运行安兔兔的测试，AS为3.01版，今天专门更新了一下，使用API 26 8.0的SDK，开启HAXM，至少某种角度来说，大家可能更关心作为普通人的自己，手上的CPU会不会有明显性能下降，还对人民群众喜闻乐见的R15也跑了一下

目前来看，除了安兔兔有一两项有明显影响外（原因还不能确定是补丁影响），总体没什么明显性能变化，大家大可不必担忧自己的PC，尤其是Windows上的常见应用的性能，Linux的情况我现在还不太清楚，目前来看影响的可能是依赖于虚拟化技术且频繁访问页表与内核的程序，但高计算密集程序无论是Linux还是Windows都不必太担心，受影响主要是云服务
晚上拿NVMe的SSD跑了一下，选3GB的大小，AS SSD的4K-64线程的写入有明显下降
未来可能会有更多Intel方面的信息透露，我也会做更多测试，目前Intel中国的反应也很懵逼

作者: any941 时间: 2018-1-5 11:18
修正下，分两个漏洞
漏洞1：spectre：AMD、Intel、ARM全部中招。可以击穿JAVA沙箱。KAISER无法拯救。

Hardware.
We have empirically verified the vulnerability
of several Intel processors to Spectre attacks, including
Ivy Bridge, Haswell and Skylake based processors.
We have also verified the attack’s applicability
to AMD Ryzen CPUs. Finally, we have also successfully
mounted Spectre attacks on several Samsung and
Qualcomm processors (which use an ARM architecture)
found in popular mobile phones.

漏洞2：meltdown：Intel中招，AMD幸免。云厂商虚拟化被严重穿透，虚拟机可以获得host内存的访问权限，及高达503kb/s的系统内存下载速度。对云厂商是致命打击。可以用KAISER拯救。

We also tried to reproduce the Meltdown bug on several
ARM and AMD CPUs. However, we did not manage
to successfully leak kernel memory with the attack described
in Section 5, neither on ARM nor on AMD. The
reasons for this can be manifold.

奉劝某些人看完论文再来评论，谢谢

We evaluated Meltdown running in containers sharing a
kernel, including Docker, LXC, and OpenVZ, and found
that the attack can be mounted without any restrictions.
Running Meltdown inside a container allows to leak information
not only from the underlying kernel, but also
from all other containers running on the same physical
host.
The commonality of most container solutions is that
every container uses the same kernel, i.e., the kernel is
shared among all containers. Thus, every container has
a valid mapping of the entire physical memory through
the direct-physical map of the shared kernel. Furthermore,
Meltdown cannot be blocked in containers, as it
uses only memory accesses. Especially with Intel TSX,
only unprivileged instructions are executed without even
trapping into the kernel.
Thus, the isolation of containers sharing a kernel can
be fully broken using Meltdown. This is especially critical
for cheaper hosting providers where users are not
separated through fully virtualized machines, but only
through containers. We verified that our attack works in
such a setup, by successfully leaking memory contents
from a container of a different user under our control.

分几个player吧：
Intel：涉及太广，产品没法召回（笔记本难道整体返厂么），赶紧明白问题根源。该道歉道歉，企业级客户该赔偿赔偿。按照5%-30%的性能衰减，相当于目前所有CPU退回一代。
AMD：太棒了亲，我没有这问题，欢迎来买！AMD性价比进一步提升。目测股价应该有所表现。
Microsoft&Apple&OtherOS：疯狂给Windows和MacOS和OtherOS搞补丁并推送。IT运维有的忙了。
云厂商：重灾区，本次的问题若被黑客利用后果不敢设想。24小时加班部署补丁，重启服务器。IAAS层的服务会出现中断并影响PAAS层和SAAS层。对于如火如荼的云化是一剂清醒剂。
别的：貌似也帮不上忙。。。

增加下某券商研报：
预测技术，Intel成也萧何败也萧何
为了提高处理效率，当代处理器内嵌有预测技术：通过预测下一条指令，处理器可以填满内部流水线，充分发挥运作效率。Intel的推测执行(Speculative Execution)技术是业界标杆水平，行业内所有公司都在向Intel靠拢，但是这个漏洞说明Intel的推测性执行在芯片内部的访存执行单元Load/Store Unit和重排序缓冲区ROB上存在安全检查漏洞，导致操作系统核心的安全保护出现问题，使得用户程序可以窥测内核数据，包括系统访问历史记录，密码等等隐私，同时会造成KASLR（Kernel Address Space Layout Randomization，内核位址空间布局随机化）的无效化，导致攻击者可以推断出内核地址，进而发动攻击控制控制整个系统，造成严重的安全风险。受影响用户包括服务器环境、PC环境和移动环境。
在Linux的源代码和邮件列表中显示，一开始的补丁也囊括了AMD CPU，但是AMD公司的工程师主动进行了修正，声明AMD的处理器不受影响并且要求取消了对AMD的补丁，目前这个补丁仅在Intel CPU上生效。
操作系统厂商纷纷发布补丁尝试修复此漏洞，但补丁会对性能造成严重影响
本次漏洞无法在芯片层面得到修复，修复只能在操作系统层面进行（或重新购买CPU）。微软预计本周四会推送补丁，且补丁已经包含在去年年底的Windows Insider版本中。苹果的MacOS也未能幸免，需要进行相应的修补工作。
本次补丁的主要功能是通过KPTI（Kernel Page Table Isolation）完全分离系统内核与用户内存，让系统使用另外一个分区表，使得用户程序无法访问系统内核。但是，KPTI会导致CPU频繁地从内核模式切换到用户模式，引发耗时的TLB缓存刷新，拉低系统效能。根据初步测试，Intel CPU效能会降低5%-30%，相当于回退1~2代。举例来说，第八代的酷睿CPU打上补丁后的效能可能低于同档次的第七代的酷睿CPU。
Intel善后花费巨大
综合专家看法，我们认为，研发方面，Intel修复本漏洞需要组织工程师Review几十万行RTL源码来确认问题所在，而发现问题后的问题解决过程将耗费更多的人力物力：我们预计Intel至少需要花费几个月的时间才能提出可行的解决方案，并做完初步测试，而采用新方案的芯片的性能将会是一个未知数；商务方面，Intel需要安抚各大客户的情绪，特别是采购了大量Intel CPU的云厂商，以防新增订单向AMD的转移，同时，对于已有的服务器设备，Intel需要与厂商一起研发解决方案堵住漏洞；品牌形象方面，Intel的高端形象无疑会遭受重创，建立品牌认知将花费较长的时间。
2016年，Intel花费了127亿美元用于研发。假设其中10%用于CPU研发，本次漏洞造成Intel CPU性能的回退至少给Intel带来了12.7亿美元的损失（相当于研发产生的性能提升被抹掉），而整体的善后成本在考虑修复成本、商务成本、品牌重建、市场竞争等因素后或将超过25亿美元。
云厂商面临巨大压力，云服务成本或有较大提升
本次的漏洞会影响所有的云厂商，包括但是不限于Amazon、Microsoft、Google等巨头。云厂商只要使用Intel CPU，就需要通过补丁进行系统加固。然而，由于云平台应用了大量的虚拟化技术，这些补丁比针对个人电脑的补丁更为复杂，由于云厂商的服务器拥有极高的数据吞吐，补丁对服务器系统效能的影响会比对PC更为严重。
Microsoft Azure将于1月10日进行维护和重启，据称跟本漏洞有关；AWS也发送了通知邮件声称本周五将进行重大安全更新。让人担心的是，已经有迹象表明有黑客在利用本漏洞攻击云系统。我们认为短期来看，云厂商的服务成本或有较大提升。

作者: xujiahui 时间: 2018-1-5 11:18
随着时间更新，情况变成了这样：

现在发现了两个严重的硬件级安全漏洞：融毁漏洞Meltdown，幽灵漏洞Spectre。
都是除了更换无漏洞CPU外无法治本。都会带来信息泄露的风险。
Meltdown就是之前所说的Intel CPU bug，覆盖面是所有支持乱序执行的Intel CPU。包括1995年起的几乎全线产品，只有少量安腾和ATOM幸免。AMD强调自己的CPU没有这个BUG，不过目前第三方还没有支持这一观点，只说待查。
Spectre影响你能看到的所有消费级CPU。包括Intel，AMD和ARM，手机也不能幸免。
Meltdown目前有了治标的办法，就是那些会降低性能的系统补丁。AMD如果确实没有这个BUG，那大概可以逃过一劫。
Spectre目前连治标的办法都没有。大家一起欢乐地裸奔……

以后会发生什么的估计和吐槽

虽然之前吐槽好像用力过度，但个人用户大量转投AMD的可能性确实不大。
反倒是最大受害者：数据中心，云服务商等组织可能会慎重考虑将一部分系统转移到AMD甚至ARM平台上了。
虽然这次他们也中枪了，但是把鸡蛋分开放，总比都堆在一个篮子里强。哪怕是最结实的篮子，最小心地看护，也不能保证永不翻车啊……
其实我有点好奇IBM POWER，龙芯之类的小众芯片有没有踩雷。乱序执行不是什么新概念，也不是x86独有的，高性能芯片一般都会有自己的实现。

和当年的心血漏洞一样，这次的严重BUG获得了专门开站介绍的待遇。大家不妨去专门的站点去看消息。
https://meltdownattack.com======================以下旧答案========================
现在的情况看起来是这样：

Intel的CPU有严重安全漏洞，会泄露信息。
除了换CPU，无法治本。
治标的办法是更新操作系统绕过漏洞。
治标会严重降低性能。

所以未来大概会这样：

个人用户Intel根本不会理睬。
也许会有人搞集体诉讼之类的活动，吃瓜群众各种嘲笑，最后不了了之。
大部分人什么都不知道。
操作系统放出补丁来，影响性能
大家发现电脑慢了，以为是老机器不行了，催生出一波换机潮
大家继续看着等灯广告买Intel

AMD崛起？不存在的。

作者: ovhmhmk 时间: 2018-1-5 11:18
我软官方回应，打补丁吧：
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002Azure已经上补丁了：
Securing Azure customers from CPU vulnerability

作者: wyo315 时间: 2018-1-5 11:18
补充新闻，等一个ibm

作者: 13633808 时间: 2018-1-5 11:18
一开始报出这个大新闻的媒体嘲讽了一下Intel的公关文，顺道cos了Trump：
We translated Intel&#x27;s crap attempt to spin its way out of CPU security bug PR nightmare==============================================
这个说的算是比较浅显易懂的。
安全专家发现英特尔处理器有重大安全问题，建议立即更新系统==============================================
Linus开喷了……
Avoid speculative indirect calls in kernelAlan Cox的回复也很有意思。
===============================================
那些给明星洗地的粉丝需要来学习一下公关文该怎么写。

我就懒得打字了，直接看下面的评论吧。

发现AMD已经针对Intel混淆视听的声明怼回去了

作者: GRcSXZPy 时间: 2018-1-5 11:18
最近业界爆出了Intel处理器猜测执行导致的漏洞。其实这个漏洞并非能够被轻易利用的那种，只是降低了黑客们侵入的门槛。
按照原生态思维，OS内核数据和代码区应该与用户区完全隔离，用户程序看到和访问的所有地址应该都是用户态地址，但是当用户程序执行系统调用时，进程会切入到内核态访问内核代码和数据，此时页表也需要从用户态页表切到内核态页表，这样性能比较差，因为页表在RAM中，纵使有TLB缓存，页表切换时之前TLB缓存的内容也会失效，要重新预热。于是目前主流OS都是将内核代码和数据区放置到每个用户进程虚拟地址空间中的高位区，32bit系统放到3~4G，windows则默认占用2~4G区，可以改为3~4G。64bit系统也放在高位。每个进程空间的内核区都被映射到同样的物理内存区中，这样，进程的切换并不会导致TLB中之前缓存的那些针对内核区的页表条目作废，保证了性能。
进程无法访问内核区，因为强行访问的话，页表条目中会有权限位，进程当前的权限被保存在CS寄存器的CPL字段中，为Ring3，而内核页表项的权限为Ring0，CPU会禁止访问并报缺页异常。
假设，OS内核爆出了某个漏洞，如果黑客向某个地址挂接或者注入代码则将取得Ring0权限。即便OS修复了该漏洞，但是有众多用户不希望打补丁，或者各种原因吧，继续裸跑，那么就有可能中招。为了“一劳永逸”的解决这个问题，或者说提高黑客们的侵入门槛，OS提供了一种机制，每次启动时，内核的代码和数据会被随机的放置在内核区，每次启动都有不同的布局，这样，即便某个漏洞被发现存在于某某地址，但是其他机器上的可不一定也是这个地址，这样，侵入程序就失去了通用性。该技术被称为ASLR（Address Space Layout Randomization）。
道高一尺魔高一丈。黑客们自有办法旁敲侧击。比如一个不透明的箱子（内核区），你想知道箱子左下角放的是什么数据，有没有数据，怎么办？敲一下听听声音，晃晃试试轻重。是的，黑客们也这么干。比如，先执行一个系统调用，sys_fork( )创建新任务，此时，CPU的TLB、L1/2/3 Cache中可能会充满与fork有关的代码和数据，调用返回后，这些内容并不会立即就被清掉，而是继续待在TLB和Cache中。然后，该程序尝试访问内核区某地址，当然这个访问会被禁止并报缺页异常。但是在被禁止之前，CPU其实是将对应地址的页表条目载入TLB，然后检查其权限发现不通过，然后才报异常。
如果程序接连发出多次访存请求访问内核区，由于目前处理器内部普遍采用提前执行的深流水线，所有这些指令都会被提前执行，提前将页表条目载入TLB，然后检查权限，不匹配则会在指令执行结果提交时报异常。但是其执行痕迹却留在了缓存中。如果程序尝试访问的内核区恰恰就是刚才所执行的系统调用相关的内容，那么缓存命中，对应条目并不会被清掉，此时程序可以尝试再次发送同样系统调用，此时会发现这个调用返回的比之前更快，这就说明了，该内核区域存放的可能就是sys_fork相关的代码和数据。如果再通过进一步的不断尝试，旁敲侧击，就可以精确判断出哪块内核代码、数据在内核虚拟区的哪里，这样，ASLR的效果就被绕过了，也就形成了漏洞。程序可以把整个内核区域都测试一遍，然后不断的分析，得出最终结论。
Intel本次爆出的漏洞，是提前执行漏洞。其与上述过程的区别在于，Intel在提前执行时，不禁将页表载入了TLB，而且连对应地址上的数据都被载入了缓存，这虽然不违反用户态永远无法直接访问内核态的原则，因为数据最终必须被载入寄存器才会被判定为“访问”，程序无法直接访问缓存，但是敏感数据已经进入了缓存，这说明Intel提前执行的力度太高。那么，这又有什么问题呢？
如果不提前执行，该越权访存指令并不会导致真的去访存，从而数据也就不会进入缓存，因为看到tlb权限不匹配就不会再去访存了，而Intel的提前执行被设计的太过激进，执行时甚至都不去检查权限，因为检查的话会增加开销，到最后检查也来得及，所以直接就去访存了，因为访存这一步比较慢，提前访存可以屏蔽访存的时延。所以，如果不提前执行，缓存中并不会有该内核地址的数据被存入，那又有什么可推断出来的结论？
如果由于提前执行而导致了有数据被存入，那么之前程序的猜测会更加精准。比如用户程序先发起一系列越权访问，导致内核某块数据载入cache，然后程序通过改变一系列调用方式重新向内核发起调用，根据调用返回时间判断本次调用是否命中了cache中的这块数据，命中了则返回更快。那么用户改变了这个参数会导致内核载入哪块数据，这个是可以通过阅读内核源码来分析出来的（Linux躺枪），在根据之前越权访问的是哪个地址？那么就可以更精准的才出来，哪块地址上存储的是哪块内核数据/代码。
所以说，Intel过于激进的提前执行，连访存都真的发生了，进入缓存了，从而让黑客有更大的可乘之机，这就是这个漏洞的技术本质。
解决办法：改硬件，提前执行不访存（性能太差），或者提前执行时就检查权限，要么就是提交时发现要回退则清除执行痕迹（Ivalid对应缓存行）。要么，该软件，OS切换为KPTI（KernelPage Table Isolation）模式，也就是重新回到原生态思维下的内核与用户态完全隔离，这样，用户态程序访问的任何地址都是用户地址，访问不了内核区。

冬瓜哥也给出一个处理方式：是不是可以在cpu内加一个寄存器用来记录内核虚拟地址边界，凡是尝试访问的，一开始就给禁掉，而不是去读页表，进tlb，检测权限。

那么，用户态到底是怎么直接拿到内核态数据的呢？在这个方法简直巧妙的令人难以置信。请看下面代码，摘自谷歌博客。其基本思想是，先越界访问，用一个越界的变量去寻址内核态数据，将读出的数据当做一个索引，与1按位与之后去寻址一个用户态的数组。让CPU的猜测执行将该数组的数据载入cache，然后考察读取两个不同数组元素，第（value&1）==0项以及（value&1）==1项，例子中就是0x200和0x300处的值，看看这两个谁返回的快，就证明value的第1个bit是1还是0，value就是内核数据。这样不断的per bit的尝试，最终dump出全部内核数据，内核裸奔~~泪哗哗的流！

https://www.zhihu.com/video/932548129002192896
                        如视频所示，hack了用于存放密码字符的地址，随着密码的输入，直接dump出来显示给你看，细思恐极啊。
更多细节邀请关注鄙人公众号：“大话存储”

作者: ADUPREce 时间: 2018-1-5 11:18
一月四日更新：

Google Zero团队发布了文章，其中的第三个bug (meltdown) 就是所说的bug
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
AMD的官方申明：An Update on AMD Processor Security （见表格的第三行，AMD不受改bug影响）

BUG大概是这个样子的（详情见Google Zero Blog）：

Mov rax, [somekerneladdress]
And rax, 1
Mov rbx,[rax+Someusermodeaddress]

这样三条指令，理论上第一条load kernel address会interrupt
但是CPU会预测执行，在最后把不应该执行的结果discard掉；也就是说第三条指令的地址可能会被load，但是不会进入rbx，因为CPU后来发现第一条指令就interrupt了
但是，第三条执行的时候这个地址进入cache了，后续可以用时间来判断cache里有哪些地址
所以就得到了kernel address的数据
---
上午在HN看到了相关讨论，自己搜了点相关信息，补充一下（不完全确定（可能现阶段只有Intel/Microsoft/Google/Apple等大厂才有人清楚情况））：

Fact: Kernel page-table isolation (KPTI, 之前叫KAISER) （wiki）在 kernel 4.15 被merge了
- KPTI是KASLR的进阶版本（内核内存地址随机化），KASLR使得内核数据结构所在地址每次启动随机，目的是基本防御通过类似overflow的方式改写内存的攻击；后来提出了一些通过side-channel（比如看执行时间来判断内存是否在cache里）绕过KASLR的攻击，于是提出了KPTI
- KPTI是给每个进程两张memory map，一块只有user space memory，一块包含kernel space memory，在进入内核态后使用后者，来进一步防止这种攻击；但是显然会带来很大的开销，每次syscall都会flush TLB，改CR3，这就是其他回答提到的性能下降5%-30%，但是对于没什么syscall的程序（比如纯计算）显然没什么影响
KPTI理应是一个“并没有什么用”的patch：它对kernel做的是防护其他漏洞出现之后增加kernel被攻击的难度，并且开销很大，理应要很久之后才merge或者根本不进入mainline。但是，这个patch在出现三个月就被merge了。
所以，大家就猜测（现在基本证实了，不过细节还是不清楚），一定是发生了一些不好的事情，比如CPU出现严重的安全性Bug了，必须要通过这个方式绕过（所以虽然KPTI很早就开始写了，但是可能最近才发现有bug使得必须要上这个patch），并且这个猜测有很多依据：
- kernel的cpu features里加了一个flag叫做X86_BUG_CPU_INSECURE
- 代码注释被删掉了
- 微软也在着急干一样的事情
- (AMD说他家的CPU不受影响…Do not enable PTI on AMD processors) （话说这个patch也是迷… if (vector != AMD) set_unsecure() ... ）
(非第一手资料) 据说邮件列表里Google和Amazon的人尤其活跃，所以猜测主要会影响虚拟机的安全性

暂时没有什么其他消息，估计要等一段时间直到几大操作系统都更新后在披露细节吧，无论如何应该会是一件非常值得期待的有趣的事情…

作者: akmpswv 时间: 2018-1-5 11:18
2018年1月4日补充：
看来AMD也难逃一劫？附微软公告截图。

原答案：
前天给老家父母订的G4560+B150+4G还在路上，原本准备年后收个二手七代U换上，这下可好，直接退了上锐龙？

作者: wz306 时间: 2018-1-5 11:18
下一代INTEL CPU牙膏都不用挤了。
修个BUG都能卖。

作者: 2125326 时间: 2018-1-5 11:18
我学习了一下，找了找资料，漏洞其实有两个，一个是Meltdown，一个是Spectre。

俩漏洞都不是去年11月的漏洞。
Meltdown，即上面大家提到的，设计bug，利用内核在内存上的映射来越级得到权限，主要影响的是Intel这边的处理器，AMD是安全的。
Spectre，则是利用其它App来达到越级的目的，不光Intel，AMD以及ARM这边 Cortex-A等等都已经沦陷，Meltdown漏洞的联合发现者自己说已经测试过漏洞攻破稳定…但是Spectre难度较Meltdown利用起来要麻烦一点点。
目前来说AMD肯定较Intel这边要安全一些的，毕竟Meltdown算是门户大开。但因为后者波及的是所有平台，所以目前没有一个系统是绝对安全的…
因为都能够最终得到系统权限，所以危险程度很高，且都是硬件级问题，所以没办法根除，和一般的软件打补丁，比如Windows的更新之类的，完全不一样。而目前靠KPTI等等打的补丁，都是牺牲性能来“补窟窿”。
因为是很“底层”，在被攻击或者被窃取信息的时候，你甚至都不容易发现自己已经被攻击了。
所有这些漏洞，都是“单机”的，并无法从网络直接利用漏洞达到目的（下载东西中毒不算……），毕竟是CPU上的，所以被利用的前提是你的系统中了病毒，所以对普通人来说，补丁尚且不论，病毒防范要做好。

参考资料：
Meltdown and Spectre

作者: MyTWbwzg 时间: 2018-1-5 11:18
AMD不受此漏洞影响... ... ...
AMD不受此漏洞影响... ...
AMD不受此漏洞影响...
AMD...
AMD ! ! !
AMD翻身之日就在此时！！！

话说Intel CPU 什么时候召回啊？！

作者: ADUPREce 时间: 2018-1-5 11:18
如果造成了这么多的性能损失，那么即使问题再严重，也会有大量的机器不会更新补丁。这才是恐怖的地方。

作者: 灬会红 时间: 2018-1-6 11:45
英文欺负没文化的

欢迎光临迅维网 (https://www.chinafix.com/)