这硬件 bug 可以说很牛了： 英特尔处理器发现严重设计漏洞， AMD 不受影响

[winglight2016]

英特尔处理器架构曝出了严重设计缺陷，目前漏洞细节还没有完全披露，而 AMD 已经确认它不受影响。修正这个芯片级的安全漏洞将会导致严重的性能惩罚，估计使用英特尔处理器的系统性能将会出现 5%- 30% 的下降。该漏洞影响所有使用英特尔处理器的操作系统，包括 Linux、Windows 和 macOS，并且迫使 Linux 和 Windows 重新设计内核的虚拟内存系统，而微码更新无法解决该问题，过去十年的英特尔处理器被认为都存在该 bug。Linux 的修复代码已经释出，被称为 Kernel Page Table Isolation （ KPTI ）的修正完全隔离了内核内存和用户进程，Phoronix 的初步测试证实性能出现了显著的下降，不过 Linux 下的游戏性能没有受到影响。微软预计会在这个月的例行更新中释出它的补丁，beta 版本已经提供给测试者。

——来自 solidot

不理解这 bug 是什么原理，怎么从硬件层面影响到了操作系统级别？

[publicccc]

操作系统就是使用的 cpu 提供的功能来隔离不同程序及内核的，现在这个隔离出了问题，意味着不同程序可以访问内核数据，其中可能存在一些密码等数据。

关键字 保护模式

www。theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

看起来安全上对单机用户可能影响不大，但是对于云服务商来讲是个大问题。
不过如果执行修复会造成悲剧的性能损失，这个会影响普通用户了。

[vjnjc]

@publicccc 这么严重啊，怪不得细节都没有完全披露。。。

[yulitian888]

想起了当年的浮点运算 bug，关键字：Pentium FDIV bug

[yulitian888]

@yulitian888 补充一下，Pentium FDIV bug 虽然和这次完全不同，但是相同的是，Intel 发现了 bug，而不处理，因为他们觉得触发这个 bug 的情况太罕见。（当年那个是直接把乘法表烧录在 CPU 里用于加速，其中几个算式录入有误）

[xratzh]

intel 那个 AMT 啥的？里面是个小系统?上次看到这个惊吓。
AMD,YES!

[Loyalsoldier]

所以修复完这个漏洞之后，今年的 8 代 i 系列相对于 7 代相当于性能没提升了……？

[rocksolid]

@Loyalsoldier 当然有提升,因为 7 代一样被修复了....

[DearMark]

性能下降真的有说得那么凶吗？

[wsy2220]

@Loyalsoldier 补丁的结果是所有 CPU 性能同时下降..

[charadeyouare]

主要是服务器的性能吧 https://news.ycombinator.com/item?id=16052451

[privil]

@Loyalsoldier #6 应该是所有 cpu 代数都降了一代

[privil]

@xratzh #5 amd 股价 up ！

[cnfzv]

不行了，这次牙膏挤得有点多，快把 amd 怼死了，得想法子补上

[cest]

io 跟 vm 性能完蛋, 掉个 20% 是回到几年前?
惨的是最吃 io, vm 的各种云, vps 还不能不 patch,以免被拿到 hypervisor 权限
个人机器倒是没差

[jimages]

云计算准备涨价

[VYSE]

https://lwn.net/SubscriberLink/741878/eb6c9d3913d7cb2b/

[affyun]

挤了好几代的牙膏，现在性能还要降一代。是时候换 AMD 了

[wkan]

AMD YES!

[evagreenworking]

xmr 矿难

[sunocean]

这个计划报废搞得有点 6, 用户还得感恩戴德你及时修复了漏洞.

[u1ucky]

AMD is the best!

[kyotrue]

CPU 在用户态的时候，只能够访问内存映射表的映射出的虚拟地址，然后再被映射到实际物理地址。这个内存映射表是由 CPU 直接访问的、操作系统在核心态管理的，利用 CPU 本身的硬件特性就实现了应用程序的可访问内存区域隔离。

而这个 bug 就是这个机制有漏洞，可以有办法绕过，更新微代码不能解决，就只能操作系统内核通过软件实现了，操作系统内核要自己再维护一层内存映射表作为中间层、通过软件来控制权限。

[we000]

PTI 这个特性我理解是 Linux Kernel 刚刚发布不久, 现在不用也就是没有了预期的性能增益而已吧? 不会让大部分用户有性能损失. 错了的话请纠正我

[jimages]

@we000 这个特性就是为了保护数据安全...代价就是性能损耗

[zmj1316]

@we000 我的理解是 Intel 发现了自己的 Bug，偷偷给内核投了个 PTI 想修了，结果被人挖出来了......

[dndx]

@we000 PTI 不是特性，是绕过 bug 的安全修复，对性能有影响。

[dndx]

@zmj1316 怎么可能，这种性能影响这么大的 patch，Linus 一声没吭火速 merge，还看不出来吗。显然是通过气的。

[xia0pia0]

据说是内核模式跟用户模式的隔离没做好，Intel 为了速度快，搞了一个推测性执行，问题就出在推测性执行上。具体细节等公布吧，反正云厂商是最头疼的。

[bukip]

"过去十年的英特尔处理器被认为都存在该 bug。"

这么久了才被发现啊，还是早就知道了。

[xenme]

所以，Intel 一直碾压 AMD 用的就是这些黑科技么？哈哈，不知道 AMD 能不能借此翻身

[we000]

@zmj1316
@jimages 你们说的对, 谢谢

[shijingshijing]

转自 wiki，中文翻译是人话版，大家凑合看。

Kernel page-table isolation
From Wikipedia, the free encyclopedia

Kernel page-table isolation (KPTI, previously called KAISER) is a hardening technique in the Linux kernel to improve security by better isolating user space and kernel space memory.[1][2] KPTI was merged into Linux kernel version 4.15,[3][4] to be released in early 2018, and backported into Linux Kernel 4.14.10. Windows implemented an identical feature in version 17035 (RS4)[5].

内核分页表隔离(KPTI，以前叫做 KAISER)是 Linux 内核中的一项加固技术，将用户空间(User Space)和内核空间(Kernel Space)的内存进行更好的隔离以增强安全。

Background[edit]
Prior to KPTI, whenever executing user space code (applications), Linux would also keep its entire kernel memory mapped in page tables, although protected from access. The advantage is that when the application makes a system call into the kernel or an interrupt is received, kernel page tables are always present, so most context switching-related overheads (TLB flush, page table swapping, etc) can be avoided.[1]

In 2005, the Linux kernel adopted address space layout randomization (KASLR), which makes it more difficult to exploit kernel vulnerabilities,[6][7] which relies on kernel addresses remaining hidden from user space. Despite prohibiting access to these kernel mappings, it turns out there are several side-channel attacks in current Intel x86 processors (as of December 2017) that can leak the location of this memory, making it possible to work around KASLR.[2][8][9][10] AMD processors are not affected by these attacks and don't need KPTI to mitigate them.[11]

背景
在 KPTI 引入之前，每次执行用户空间代码（应用）时，Linux 虽然（对内核存储区域（ Kernel Memory ））进行了访问保护，但还是会继续将整个内核存储区域（ Kernel Memory ）映射在分页表（ page table ）中。这样做的好处是，应用程序（ Application ）在请求内核系统调用（ make a system call ）或者触发一个中断（ interrupt ）时，内核的分页表一直处于可用状态，这样绝大多数上下文切换相关的开销（ TLB Flush，page table swapping，等）可以避免。

在 2005 年，Linux 内核引入了地址空间随机排布技术（ KASLR ），让内核地址对用户空间不可见，从而增加了发现内核漏洞的难度。虽然（已经）禁止了对这些内核映射的访问，但最后发现在现有的 Intel X86 处理器（到 2017 年 12 月为止）上可能会泄漏这些内存的位置，有一些旁路攻击（ side-channel attacks ）可以绕过 KASLR （这里是指通过 Kernel Page Table 里面的映射关系，能获取到 Kernel 内存区域的地址）。AMD 的处理器则不会受到这些攻击的影响因此无需使用 KPTI 进行改善。

Implementation[edit]
KPTI fixes these leaks by separating user space and kernel space page tables entirely. On recent x86 processors, a TLB flush can be avoided using the process context identifiers (PCID) feature, but even then it comes at a significant performance cost particularly in syscall-heavy and interrupt-heavy workloads. The overhead[clarification needed] was measured to be 0.28% according to KAISER's original authors,[2] but roughly 5% for most workloads by a Linux developer.[1]

KPTI can be disabled with the "nopti" kernel boot option. Also provisions were created to disable KPTI if newer processors fix the information leaks.[3]

实现
KPTI 通过对用户空间和内核空间的分页表进行完全隔离来修复这项漏洞。在最新的 X86 处理器中，使用 PCID （进程上下文标识符）来避免产生 TLB flush，即使这样，仍然会带来显著降低性能，特别是频繁使用系统调用和频繁使用中断的应用程序。由此带来的开销根据 KAISER 的原作者测量约 0.28%；一位 Linux 开发人员的测量结果是大多数工况下有 5%。

KPTI 可以通过 nopti 内核启动选项进行关闭。此外也做了未来如果新的处理器修复了此项漏洞，对 KPTI 进行关闭的准备。

--------------------------------------------------------

个人理解，问题可能是出在 Intel 处理器的 MMU 上，page table 的映射以及 address translation 是通过硬件实现的，可能是这一块出了问题，不得不用软件进行一些预处理。

[hadoop]

amd is the best!

[zmj1316]

@dndx 内核开发的肯定知道啊，偷偷说的是不公开说

https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/?sort=confidence

这里写了，
People have noticed a recent development in the Linux kernel: a rather massive, important redesign (page table isolation) is being introduced very fast for kernel standards... and being backported! The "official" reason is to incorporate a mitigation called KASLR... which most security experts consider almost useless

根本没对外提 PTI 是拿来修硬件 Bug 的，估计是想先把 Patch 推了再公布漏洞

[VYSE]

评论误区太多
KPTI 概念来自于 KAISER https://gruss.cc/files/kaiser.pdf
KAISER 目的是因为历史上一票针对 CPU 的边信道攻击, 导致 KASLR 变得没什么卵用
边信道攻击是个大难题,KPTI 只能解决某些问题
AMD 并非不受边信道攻击,例如

[tyfyc]

我早发那么久就一回复。。。估计确实被降权了。。。

https://lkml.org/lkml/2017/12/4/709

Linux 的 Patch 12 月 4 号就已经在 mailing list 了
原来开源社区早就被大厂商吃定了，孤陋寡闻了

[Microi]

什么？我已经 49 入国军了，还要被捅一刀？

[pq]

最近，Intel 被连曝负面新闻，难道是要被做空了么？

[realpg]

是否给用户一个选项不修复这个漏洞？

[winglight2016]

@kyotrue 原来是这样，那我明白了，只是这个补丁居然会导致 20%的性能损失，还过了十年多才发现，这也太～～～

[zpf124]

@winglight2016 准确的说是几年前发现，然后吭哧吭哧想了半天办法应该是最近才要完成修复了的。

所以这种重大性质的 bug 才会公之于众允许讨论。

[winglight2016]

@zpf124 一个 bug 需要几年的时间来修复？这点我难以想象～～～

[mh4cx3r]

已验证的受影响的 CPU

[redsonic]

这届 34C3 让人感觉要把 ASM.js 这类东西禁了才好一些，对于一般用户的终端机。
@VYSE

[wevsty]

@mh4cx3r
为什么非 Intel 的 CPU 也会有影响？不太明白。

[fy]

害怕 话说上面那个 ARM 架构的什么路数啊？

[dcll222]

看起来 amd 和 arm 都不能免俗

[yexm0]

我的天。。。连手机也中招了？

[loading]

linux 游戏性能未受影响…

[sadscv]

Intel: 下一代产品懒得挤牙膏了，但我还可以把以前产品的牙膏吸回去，没想到吧！

[hadoop]

我可以选择自己的电脑不修复吗

[winglight2016]

@sadscv 万万没想到系列～～～

[iwtbauh]

@realpg
@hadoop
Linux 用户理论上可以自行给内核打补丁，去掉这个修复。Windows 用户只能选择不升级，Wikipedia 上说 win10 的 17035 （ RS4 ）版本“实现了相同的功能”（个人理解修复了这个 bug ）

[zk8802]

这个漏洞好像是在 speculative execution 中的一个 timing side-channel。Intel 表示不是他们的问题，我认为是有一定道理的。Intel 在设计时可能压根没考虑到 speculative execution 中会有 side-channel 漏洞，因此也就没做相应的 verification。

VuSec 的一个人做了 PoC: https://twitter.com/brainsmoke/status/948561799875502080

Intel 的声明: https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

供参考。

[zpf124]

@winglight2016 改代码本身很容易，但这个漏洞的修复会导致性能爆降这就值得权衡 和 思考有没有其他解决方案了。

不了解具体的实际流程，但估计可能是这样的。

三到四年前某大神报告有这个安全隐患，然后知道这个消息的 intel 和其他大厂技术人员尝试看看这个漏洞能否被利用，花了大半年到一年时间，某一位确实验证了这个攻击的可能性。

然后一群大佬再尝试研究如何解决，最简单粗暴的方法就是这处功能有问题，那直接绕过不使用这个功能就好了；此外他们肯定也想找到什么更好的解决方案。 估计这里想找个更好的解决方案还得再花个一年半到两年。

而这一两年这个隐秘的内部消息也在逐渐扩大流传范围，而这么久了还没有研究出更巧妙的解决方案。再等这个消息没准就会扩大到大部分的高端程序员这一层，
所以各大厂商先按照笨办法修复，估计也就一两个月就改好了，然后再测试半年。

最后公布可能会出现这个漏洞，让非核心的其他计算机相关公司也得知警惕这个消息。

[expy]

机智的 AMD，https://lkml.org/lkml/2017/12/27/2

[winglight2016]

@zpf124 按星期迭代产品的表示无法理解以半年为单位修复 bug ～～～关键是几个半年过去了，还搞不定。

也可能是硬件问题难以解决吧，我对硬件是只懂了六窍。。。

[liaoyaoheng]

关键是，影响那些 cpu，应该列所有。

[lry]

想知道哪些 linux 的发行版(内核版本)已经推送了 KPTI 补丁更新。。

[fy]

@lry #59 当前 arch 内核：linux49-4.9.73-1-x86_64，应该已经有了吧？可能更早？

[honeycomb]

可以去看 project zero 的博客，它们已经给出相对详细的具体漏洞描述了。

AMD 的产品至少不受其中一个漏洞影响，另两个则存疑

[UnknownR]

蛋疼，刚刚紧急宣布要加班

[liaoyaoheng]

不用傻瓜般的虚拟内存的我路过

[iwtbauh]

@lry
ubuntu 16.04 LTS 似乎尚未打 KPTI 补丁

```
$ apt-get source linux-image-$(uname -r)
正在读取软件包列表... 完成
选择 linux-hwe 作为源代码包而非 linux-image-4.10.0-42-generic
提示：linux-hwe 的打包工作被维护于以下位置的 Git 版本控制系统中：
......
需要下载 153 MB 的源代码包。
......
已下载 153 MB，耗时 2 分 20 秒 (1,095 kB/s)
```

```
cd linux-hwe-4.10.0/arch/x86/kernel/cpu
grep "X86_BUG_CPU_INSECURE" common.c
```

没有输出

[iwtbauh]

@liaoyaoheng 虚拟内存怎么可能不用，现代操作系统高度依赖虚拟内存才能正确工作
你可能对虚拟内存有误解，虚拟内存不是 windows 的“页面文件”，*nix 的“ swap ”： https://en.wikipedia.org/wiki/Virtual_memory

[zo]

服务器都挂了