Gerg：Meltdown 和 Spectre 影响下的 Linux 内核状况
KPTI Meltdown Spectre
![](/data/attachment/album/201802/09/211831lzys5xy9p0nxylxx.png)


现在（LCTT 译注：本文发表于 1 月初），每个人都知道一件关乎电脑安全的“大事”发生了，真见鬼，等[每日邮报报道](http://www.dailymail.co.uk/sciencetech/article-5238789/Intel-says-security-updates-fix-Meltdown-Spectre.html)的时候，你就知道什么是糟糕了...


不管怎样，除了告诉你这篇写的及其出色的[披露该问题的 Zero 项目的论文](https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html)之外，我不打算去跟进这个问题已经被报道出来的细节。他们应该现在就直接颁布 2018 年的 [Pwnie](https://pwnies.com/) 奖，干的太棒了。


如果你想了解我们如何在内核中解决这些问题的技术细节，你可以保持关注了不起的 [lwn.net](https://lwn.net/Articles/743265/)，他们会把这些细节写成文章。


此外，这有一条很好的关于[这些公告](https://lwn.net/Articles/742999/)的摘要，包括了各个厂商的公告。


至于这些涉及的公司是如何处理这些问题的，这可以说是如何**不**与 Linux 内核社区保持沟通的教科书般的例子。这件事涉及到的人和公司都知道发生了什么，我确定这件事最终会出现，但是目前我需要去关注的是如何修复这些涉及到的问题，然后不去点名指责，不管我有多么的想去这么做。


### 你现在能做什么


如果你的 Linux 系统正在运行一个正常的 Linux 发行版，那么升级你的内核。它们都应该已经更新了，然后在接下来的几个星期里保持更新。我们会统计大量在极端情况下出现的 bug ，这里涉及的测试很复杂，包括庞大的受影响的各种各样的系统和工作任务。如果你的 Linux 发行版没有升级内核，我强烈的建议你马上更换一个 Linux 发行版。


然而有很多的系统因为各种各样的原因（听说它们比起“传统”的企业发行版更多）不是在运行“正常的” Linux 发行版上。它们依靠长期支持版本（LTS）的内核升级，或者是正常的稳定内核升级，或者是内部的某人打造版本的内核。对于这部分人，这篇介绍了你能使用的上游内核中发生的混乱是怎么回事。


### Meltdown – x86


现在，Linus 的内核树包含了我们当前所知的为 x86 架构解决 meltdown 漏洞的所有修复。开启 `CONFIG_PAGE_TABLE_ISOLATION` 这个内核构建选项，然后进行重构和重启，所有的设备应该就安全了。


然而，Linus 的内核树当前处于 4.15-rc6 这个版本加上一些未完成的补丁。4.15-rc7 版本要明天才会推出，里面的一些补丁会解决一些问题。但是大部分的人不会在一个“正常”的环境里运行 -rc 内核。


因为这个原因，x86 内核开发者在<ruby> 页表隔离 <rt>  page table isolation </rt></ruby>代码的开发过程中做了一个非常好的工作，好到要反向移植到最新推出的稳定内核 4.14 的话，我们只需要做一些微不足道的工作。这意味着最新的 4.14 版本（本文发表时是 4.14.12 版本），就是你应该运行的版本。4.14.13 会在接下来的几天里推出，这个更新里有一些额外的修复补丁，这些补丁是一些运行 4.14.12 内核且有启动时间问题的系统所需要的（这是一个显而易见的问题，如果它不启动，就把这些补丁加入更新排队中）。


我个人要感谢 Andy Lutomirski、Thomas Gleixner、Ingo Molnar、 Borislav Petkov、 Dave Hansen、 Peter Zijlstra、 Josh Poimboeuf、 Juergen Gross 和 Linus Torvalds。他们开发出了这些修复补丁，并且为了让我能轻松地使稳定版本能够正常工作，还把这些补丁以一种形式融合到了上游分支里。没有这些工作，我甚至不敢想会发生什么。


对于老的长期支持内核（LTS），我主要依靠 Hugh Dickins、 Dave Hansen、 Jiri Kosina 和 Borislav Petkov 优秀的工作，来为 4.4 到 4.9 的稳定内核代码树分支带去相同的功能。我同样在追踪讨厌的 bug 和缺失的补丁方面从 Guenter Roeck、 Kees Cook、 Jamie Iles 以及其他很多人那里得到了极大的帮助。我要感谢 David Woodhouse、 Eduardo Valentin、 Laura Abbott 和 Rik van Riel 在反向移植和集成方面的帮助，他们的帮助在许多棘手的地方是必不可少的。


这些长期支持版本的内核同样有 `CONFIG_PAGE_TABLE_ISOLATION` 这个内核构建选项，你应该开启它来获得全方面的保护。


从主线版本 4.14 和 4.15 的反向移植是非常不一样的，它们会出现不同的 bug，我们现在知道了一些在工作中遇见的 VDSO 问题。一些特殊的虚拟机安装的时候会报一些奇怪的错，但这是只是现在出现的少数情况，这种情况不应该阻止你进行升级。如果你在这些版本中遇到了问题，请让我们在稳定内核邮件列表中知道这件事。


如果你依赖于 4.4 和 4.9 或是现在的 4.14 以外的内核代码树分支，并且没有发行版支持你的话，你就太不幸了。比起你当前版本内核包含的上百个已知的漏洞和 bug，缺少补丁去解决 meltdown 问题算是一个小问题了。你现在最需要考虑的就是马上把你的系统升级到最新。


与此同时，臭骂那些强迫你运行一个已被废弃且不安全的内核版本的人，他们是那些需要知道这是完全不顾后果的行为的人中的一份子。


### Meltdown – ARM64


现在 ARM64 为解决 Meltdown 问题而开发的补丁还没有并入 Linus 的代码树，一旦 4.15 在接下来的几周里成功发布，他们就准备[阶段式地并入](https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti) 4.16-rc1，因为这些补丁还没有在一个 Linus 发布的内核中，我不能把它们反向移植进一个稳定的内核版本里（额……我们有这个[规矩](https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html)是有原因的）


由于它们还没有在一个已发布的内核版本中，如果你的系统是用的 ARM64 的芯片（例如 Android ），我建议你选择 [Android 公共内核代码树](https://android.googlesource.com/kernel/common/)，现在，所有的 ARM64 补丁都并入 [3.18](https://android.googlesource.com/kernel/common/+/android-3.18)、[4.4](https://android.googlesource.com/kernel/common/+/android-4.4) 和 [4.9](https://android.googlesource.com/kernel/common/+/android-4.9) 分支 中。


我强烈建议你关注这些分支，看随着时间的过去，由于测试了已并入补丁的已发布的上游内核版本，会不会有更多的修复补丁被补充进来，特别是我不知道这些补丁会在什么时候加进稳定的长期支持内核版本里。


对于 4.4 到 4.9 的长期支持内核版本，这些补丁有很大概率永远不会并入它们，因为需要大量的先决补丁。而所有的这些先决补丁长期以来都一直在 Android 公共内核版本中测试和合并，所以我认为现在对于 ARM 系统来说，仅仅依赖这些内核分支而不是长期支持版本是一个更好的主意。


同样需要注意的是，我合并所有的长期支持内核版本的更新到这些分支后通常会在一天之内或者这个时间点左右进行发布，所以你无论如何都要关注这些分支，来确保你的 ARM 系统是最新且安全的。


### Spectre


现在，事情变得“有趣”了……


再一次，如果你正在运行一个发行版的内核，一些内核融入了各种各样的声称能缓解目前大部分问题的补丁，你的内核*可能*就被包含在其中。如果你担心这一类的攻击的话，我建议你更新并测试看看。


对于上游来说，很好，现状就是仍然没有任何的上游代码树分支合并了这些类型的问题相关的修复补丁。有很多的邮件列表在讨论如何去解决这些问题的解决方案，大量的补丁在这些邮件列表中广为流传，但是它们尚处于开发前期，一些补丁系列甚至没有被构建或者应用到任何已知的代码树，这些补丁系列彼此之间相互冲突，这是常见的混乱。


这是由于 Spectre 问题是最近被内核开发者解决的。我们所有人都在 Meltdown 问题上工作，我们没有精确的 Spectre 问题全部的真实信息，而四处散乱的补丁甚至比公开发布的补丁还要糟糕。


因为所有的这些原因，我们打算在内核社区里花上几个星期去解决这些问题并把它们合并到上游去。修复补丁会进入到所有内核的各种各样的子系统中，而且在它们被合并后，会集成并在稳定内核的更新中发布，所以再次提醒，无论你使用的是发行版的内核还是长期支持的稳定内核版本，你最好并保持更新到最新版。


这不是好消息，我知道，但是这就是现实。如果有所安慰的话，似乎没有任何其它的操作系统完全地解决了这些问题，现在整个产业都在同一条船上，我们只需要等待，并让开发者尽快地解决这些问题。


提出的解决方案并非毫不重要，但是它们中的一些还是非常好的。一些新概念会被创造出来来帮助解决这些问题，Paul Turner 提出的 Retpoline 方法就是其中的一个例子。这将是未来大量研究的一个领域，想出方法去减轻硬件中涉及的潜在问题，希望在它发生前就去预见它。


### 其他架构的芯片


现在，我没有看见任何 x86 和 arm64 架构以外的芯片架构的补丁，听说在一些企业发行版中有一些用于其他类型的处理器的补丁，希望他们在这几周里能浮出水面，合并到合适的上游那里。我不知道什么时候会发生，如果你使用着一个特殊的架构，我建议在 arch-specific 邮件列表上问这件事来得到一个直接的回答。


### 结论


再次说一遍，更新你的内核，不要耽搁，不要止步。更新会在很长的一段时间里持续地解决这些问题。同样的，稳定和长期支持内核发行版里仍然有很多其它的 bug 和安全问题，它们和问题的类型无关，所以一直保持更新始终是一个好主意。


现在，有很多非常劳累、坏脾气、缺少睡眠的人，他们通常会生气地让内核开发人员竭尽全力地解决这些问题，即使这些问题完全不是开发人员自己造成的。请关爱这些可怜的程序猿。他们需要爱、支持，我们可以为他们免费提供的他们最爱的饮料，以此来确保我们都可以尽可能快地结束修补系统。




---


via: <http://kroah.com/log/blog/2018/01/06/meltdown-status/>


作者：[Greg Kroah-Hartman](http://kroah.com) 译者：[hopefully2333](https://github.com/hopefully2333) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
By now, everyone knows that something “big” just got announced regarding
computer security. Heck, when the
[Daily Mail does a report on it](http://www.dailymail.co.uk/sciencetech/article-5238789/Intel-says-security-updates-fix-Meltdown-Spectre.html)
, you know something is bad…

Anyway, I’m not going to go into the details about the problems being
reported, other than to point you at the wonderfully written
[Project Zero paper on the issues involved here](https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html).
They should just give out the 2018 [Pwnie](https://pwnies.com/) award
right now, it’s that amazingly good.

If you do want technical details for how we are resolving those issues
in the kernel, see the always awesome [lwn.net writeup for the details](https://lwn.net/Articles/743265/).

Also, here’s a good summary of [lots of other postings](https://lwn.net/Articles/742999/) that includes announcements
from various vendors.

As for how this was all handled by the companies involved, well this
could be described as a textbook example of how *NOT* to interact with
the Linux kernel community properly. The people and companies involved
know what happened, and I’m sure it will all come out eventually, but
right now we need to focus on fixing the issues involved, and not
pointing blame, no matter how much we want to.

## What you can do right now

If your Linux systems are running a normal Linux distribution, go update your kernel. They should all have the updates in them already. And then keep updating them over the next few weeks, we are still working out lots of corner case bugs given that the testing involved here is complex given the huge variety of systems and workloads this affects. If your distro does not have kernel updates, then I strongly suggest changing distros right now.

However there are lots of systems out there that are not running “normal” Linux distributions for various reasons (rumor has it that it is way more than the “traditional” corporate distros). They rely on the LTS kernel updates, or the normal stable kernel updates, or they are in-house franken-kernels. For those people here’s the status of what is going on regarding all of this mess in the upstream kernels you can use.

## Meltdown – x86

Right now, Linus’s kernel tree contains all of the fixes we currently know about to handle the Meltdown vulnerability for the x86 architecture. Go enable the CONFIG_PAGE_TABLE_ISOLATION kernel build option, and rebuild and reboot and all should be fine.

However, Linus’s tree is currently at 4.15-rc6 + some outstanding patches. 4.15-rc7 should be out tomorrow, with those outstanding patches to resolve some issues, but most people do not run a -rc kernel in a “normal” environment.

Because of this, the x86 kernel developers have done a wonderful job in their development of the page table isolation code, so much so that the backport to the latest stable kernel, 4.14, has been almost trivial for me to do. This means that the latest 4.14 release (4.14.12 at this moment in time), is what you should be running. 4.14.13 will be out in a few more days, with some additional fixes in it that are needed for some systems that have boot-time problems with 4.14.12 (it’s an obvious problem, if it does not boot, just add the patches now queued up.)

I would personally like to thank Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, Peter Zijlstra, Josh Poimboeuf, Juergen Gross, and Linus Torvalds for all of the work they have done in getting these fixes developed and merged upstream in a form that was so easy for me to consume to allow the stable releases to work properly. Without that effort, I don’t even want to think about what would have happened.

For the older long term stable (LTS) kernels, I have leaned heavily on the wonderful work of Hugh Dickins, Dave Hansen, Jiri Kosina and Borislav Petkov to bring the same functionality to the 4.4 and 4.9 stable kernel trees. I had also had immense help from Guenter Roeck, Kees Cook, Jamie Iles, and many others in tracking down nasty bugs and missing patches. I want to also call out David Woodhouse, Eduardo Valentin, Laura Abbott, and Rik van Riel for their help with the backporting and integration as well, their help was essential in numerous tricky places.

These LTS kernels also have the CONFIG_PAGE_TABLE_ISOLATION build option that should be enabled to get complete protection.

As this backport is very different from the mainline version that is in 4.14 and 4.15, there are different bugs happening, right now we know of some VDSO issues that are getting worked on, and some odd virtual machine setups are reporting strange errors, but those are the minority at the moment, and should not stop you from upgrading at all right now. If you do run into problems with these releases, please let us know on the stable kernel mailing list.

If you rely on any other kernel tree other than 4.4, 4.9, or 4.14 right now, and you do not have a distribution supporting you, you are out of luck. The lack of patches to resolve the Meltdown problem is so minor compared to the hundreds of other known exploits and bugs that your kernel version currently contains. You need to worry about that more than anything else at this moment, and get your systems up to date first.

Also, go yell at the people who forced you to run an obsoleted and insecure kernel version, they are the ones that need to learn that doing so is a totally reckless act.

## Meltdown – ARM64

Right now the ARM64 set of patches for the Meltdown issue are not merged
into Linus’s tree. They are [staged and ready to be merged](https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti)
into 4.16-rc1 once 4.15 is released in a few weeks. Because these
patches are not in a released kernel from Linus yet, I can not backport
them into the stable kernel releases (hey, we have [rules](https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html)
for a reason…)

Due to them not being in a released kernel, if you rely on ARM64 for
your systems (i.e. Android), I point you at the
[Android Common Kernel tree](https://android.googlesource.com/kernel/common/)
All of the ARM64 fixes have been merged into the
[3.18,](https://android.googlesource.com/kernel/common/+/android-3.18)
[4.4,](https://android.googlesource.com/kernel/common/+/android-4.4)
and
[4.9 branches](https://android.googlesource.com/kernel/common/+/android-4.9)
as of this point in time.

I would strongly recommend just tracking those branches as more fixes get added over time due to testing and things catch up with what gets merged into the upstream kernel releases over time, especially as I do not know when these patches will land in the stable and LTS kernel releases at this point in time.

For the 4.4 and 4.9 LTS kernels, odds are these patches will never get merged into them, due to the large number of prerequisite patches required. All of those prerequisite patches have been long merged and tested in the android-common kernels, so I think it is a better idea to just rely on those kernel branches instead of the LTS release for ARM systems at this point in time.

Also note, I merge all of the LTS kernel updates into those branches usually within a day or so of being released, so you should be following those branches no matter what, to ensure your ARM systems are up to date and secure.

## Spectre

Now things get “interesting”…

Again, if you are running a distro kernel, you *might* be covered as
some of the distros have merged various patches into them that they
claim mitigate most of the problems here. I suggest updating and
testing for yourself to see if you are worried about this attack vector

For upstream, well, the status is there is no fixes merged into any upstream tree for these types of issues yet. There are numerous patches floating around on the different mailing lists that are proposing solutions for how to resolve them, but they are under heavy development, some of the patch series do not even build or apply to any known trees, the series conflict with each other, and it’s a general mess.

This is due to the fact that the Spectre issues were the last to be addressed by the kernel developers. All of us were working on the Meltdown issue, and we had no real information on exactly what the Spectre problem was at all, and what patches were floating around were in even worse shape than what have been publicly posted.

Because of all of this, it is going to take us in the kernel community a few weeks to resolve these issues and get them merged upstream. The fixes are coming in to various subsystems all over the kernel, and will be collected and released in the stable kernel updates as they are merged, so again, you are best off just staying up to date with either your distribution’s kernel releases, or the LTS and stable kernel releases.

It’s not the best news, I know, but it’s reality. If it’s any consolation, it does not seem that any other operating system has full solutions for these issues either, the whole industry is in the same boat right now, and we just need to wait and let the developers solve the problem as quickly as they can.

The proposed solutions are not trivial, but some of them are amazingly
good. The [Retpoline](https://support.google.com/faqs/answer/7625886)
post from Paul Turner is an example of some of the new concepts being
created to help resolve these issues. This is going to be an area of
lots of research over the next years to come up with ways to mitigate
the potential problems involved in hardware that wants to try to predict
the future before it happens.

## Other arches

Right now, I have not seen patches for any other architectures than x86 and arm64. There are rumors of patches floating around in some of the enterprise distributions for some of the other processor types, and hopefully they will surface in the weeks to come to get merged properly upstream. I have no idea when that will happen, if you are dependant on a specific architecture, I suggest asking on the arch-specific mailing list about this to get a straight answer.

## Conclusion

Again, update your kernels, don’t delay, and don’t stop. The updates to resolve these problems will be continuing to come for a long period of time. Also, there are still lots of other bugs and security issues being resolved in the stable and LTS kernel releases that are totally independent of these types of issues, so keeping up to date is always a good idea.

Right now, there are a lot of very overworked, grumpy, sleepless, and just generally pissed off kernel developers working as hard as they can to resolve these issues that they themselves did not cause at all. Please be considerate of their situation right now. They need all the love and support and free supply of their favorite beverage that we can provide them to ensure that we all end up with fixed systems as soon as possible.