任何与状态更新有关的问题，或者询问是否会修补这些漏洞的问题都应作为该问题的重复而关闭。
Meltdown 和 Spectre现在新闻里都是这样的，听起来很严重。我没有看到 Ubuntu 有任何安全更新可以解决这些漏洞。
Ubuntu 针对这些漏洞采取了什么措施？Ubuntu 用户又应该做什么呢？
这些是 CVE-2017-5753、CVE-2017-5715 和 CVE-2017-5754。
答案1
我们发现，一种新型旁道攻击会影响大多数处理器，包括英特尔、AMD 和 ARM 的处理器。这种攻击允许恶意用户空间进程读取内核内存，并允许客户机中的恶意代码读取虚拟机管理程序内存。
为了解决这个问题，需要更新 Ubuntu 内核和处理器微码。更新将于Ubuntu 安全声明。Meltdown/Spectre 相关更新现已公布，涵盖内核和一些用户空间软件的更新。
已发布以下更新：
- Ubuntu 内核更新现已发布USN 3522-1（适用于 Ubuntu 16.04 LTS），USN 3523-1（适用于 Ubuntu 17.10），USN 3522-2（适用于 Ubuntu 14.04 LTS (HWE)），以及USN-3524-1（适用于 Ubuntu 14.04 LTS）。
- 进一步的内核更新（包括针对 Spectre 变体的缓解措施和针对 Meltdown 的其他缓解措施）已于 2018 年 1 月 22 日发布，USN-3541-2（适用于 Ubuntu 16.04 LTS (HWE)），USN-3540-1（适用于 Ubuntu 16.04 LTS），USN-3541-1（适用于 Ubuntu 17.10），USN-3540-2（适用于 Ubuntu 14.04 LTS (HWE)），USN-3542-1（适用于 Ubuntu 14.04 LTS），USN-3542-2（适用于 Ubuntu 12.04 LTS（HWE））。
- USN-3516-1提供 Firefox 更新。
- USN-3521-1提供 NVIDIA 驱动程序更新。
USN-3531-1提供英特尔微码更新。由于回归，微码更新目前已恢复（USN-3531-2）。
用户应在更新发布后立即安装以正常方式. 需要重新启动才能使内核和微码更新生效。
用户可以验证内核页表隔离补丁是否有效重启后。
不会提供 Ubuntu 17.04 (Zesty Zapus) 的更新就像它已到达使用寿命2018年1月13日。
在安全更新发布之前，Dustin Kirkland 提供了一些有关更新的详细信息。博客文章，包括提及内核更新以及 CPU 微码、gcc 和 qemu 更新。
Canonical 的 Kiko Reis 写了一篇这些漏洞的影响及其缓解措施的可访问描述于 2018 年 1 月 24 日面向 Ubuntu 用户推出。
Ubuntu 安全团队维持这些问题的现状和官方技术常见问题解答详细介绍了特定单个漏洞变体及其在不同用例下的缓解措施。
请注意，从 v4.15（2018 年 1 月 28 日）开始的 Linux 主线和稳定版本更新包含相应的修复，Ubuntu 内核基于这些修复。因此，使用 Linux 内核版本 4.15.0 及更高版本的任何 Ubuntu 版本都已修补（包括 18.04 和 18.10）。
答案2
这里需要记住一些具体的事情，这些是从我所在的一些不仅限于 Ubuntu 的分析和安全邮件列表中收集的：
这崩溃攻击可以在内核级别进行修补。这将有助于防范 Meltdown 漏洞。
这幽灵攻击载体更难防御，但坏人也更难利用。虽然有针对已知攻击媒介，例如可以修补的 LLVM 攻击媒介，核心问题是，要真正修复 Spectre，你必须改变 CPU 硬件的工作和行为方式。这使得防御难度大大增加，因为只有已知攻击媒介确实可以修补。不过，每款软件都需要针对此问题进行单独强化，这意味着这是“一个补丁无法解决所有问题”的一种情况。
现在，我们来讨论一下大问题：
- Ubuntu 会修补 Meltdown 和 Spectre 漏洞吗？
- 答案是是的，但做起来很棘手，补丁会慢慢进入内核，但内核和安全团队会在进行过程中进行测试，并且可能会在此过程中看到意想不到的回归，他们必须打补丁来修复意外的问题。安全和内核团队是正在努力。
什么时候会有修复吗？
我会给你与内核团队相同的答案：“当我们确信补丁能够发挥作用，并且不会在过程中对任何其他事物造成重大破坏时。”
现在，需要考虑的一件大事是：曾是公开披露的目标日期是 1 月 9 日，这应该与修复程序的发布一致。然而，披露日期却定在了 1 月 3 日。内核团队和安全团队仍将目标定在 1 月 9 日，然而，这并不是一个确定的最后期限，如果内核在此过程中出现任何重大问题，可能会出现延迟
我应该在什么地方寻找有关 Meltdown 和 Spectre 的更多更新？
您应该关注的其他相关链接：
答案3
2018 年 1 月 20 日
Spectre 保护（雷特波林) 由 Linux 内核团队于 2018 年 1 月 15 日发布，适用于内核 4.9.77 和 4.14.14。Ubuntu 内核团队仅在 2018 年 1 月 17 日发布了内核版本 4.9.77，尚未发布内核版本 4.14.14。原因尚不清楚，但 4.14.14 已被重新请求，如 Ask Ubuntu 中的答案：为什么发布了内核 4.9.77，但没有发布内核 4.14.14？直到今天才出现。
2018 年 1 月 17 日 为 Meltdown 添加 Spectre 支持
我认为有些人会对 4.14.14（从 4.14.13 开始）的变化感兴趣，正如程序员评论中所述，我认为对于内核 C 程序员来说这些评论非常详细，以我有限的经验来说。以下是从 4.14.13 到 4.14.14 内核的变化，主要关注幽灵支持：
+What: /sys/devices/system/cpu/vulnerabilities
+ /sys/devices/system/cpu/vulnerabilities/meltdown
+ /sys/devices/system/cpu/vulnerabilities/spectre_v1
+ /sys/devices/system/cpu/vulnerabilities/spectre_v2
+Date: January 2018
+Contact: Linux kernel mailing list <[email protected]>
+Description: Information about CPU vulnerabilities
+
+ The files are named after the code names of CPU
+ vulnerabilities. The output of those files reflects the
+ state of the CPUs in the system. Possible output values:
+
+ "Not affected" CPU is not affected by the vulnerability
+ "Vulnerable" CPU is affected and no mitigation in effect
+ "Mitigation: $M" CPU is affected and mitigation $M is in effect
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 520fdec15bbb..8122b5f98ea1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2599,6 +2599,11 @@
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
+ nospectre_v2 [X86] Disable all mitigations for the Spectre variant 2
+ (indirect branch prediction) vulnerability. System may
+ allow data leaks with this option, which is equivalent
+ to spectre_v2=off.
+
noxsave [BUGS=X86] Disables x86 extended register state save
and restore using xsave. The kernel will fallback to
enabling legacy floating-point and sse state.
@@ -2685,8 +2690,6 @@
steal time is computed, but won't influence scheduler
behaviour
- nopti [X86-64] Disable kernel page table isolation
-
nolapic [X86-32,APIC] Do not enable or use the local APIC.
nolapic_timer [X86-32,APIC] Do not use the local APIC timer.
@@ -3255,11 +3258,20 @@
pt. [PARIDE]
See Documentation/blockdev/paride.txt.
- pti= [X86_64]
- Control user/kernel address space isolation:
- on - enable
- off - disable
- auto - default setting
+ pti= [X86_64] Control Page Table Isolation of user and
+ kernel address spaces. Disabling this feature
+ removes hardening, but improves performance of
+ system calls and interrupts.
+
+ on - unconditionally enable
+ off - unconditionally disable
+ auto - kernel detects whether your CPU model is
+ vulnerable to issues that PTI mitigates
+
+ Not specifying this option is equivalent to pti=auto.
+
+ nopti [X86_64]
+ Equivalent to pti=off
pty.legacy_count=
[KNL] Number of legacy pty's. Overwrites compiled-in
@@ -3901,6 +3913,29 @@
sonypi.*= [HW] Sony Programmable I/O Control Device driver
See Documentation/laptops/sonypi.txt
+ spectre_v2= [X86] Control mitigation of Spectre variant 2
+ (indirect branch speculation) vulnerability.
+
+ on - unconditionally enable
+ off - unconditionally disable
+ auto - kernel detects whether your CPU model is
+ vulnerable
+
+ Selecting 'on' will, and 'auto' may, choose a
+ mitigation method at run time according to the
+ CPU, the available microcode, the setting of the
+ CONFIG_RETPOLINE configuration option, and the
+ compiler with which the kernel was built.
+
+ Specific mitigations can also be selected manually:
+
+ retpoline - replace indirect branches
+ retpoline,generic - google's original retpoline
+ retpoline,amd - AMD-specific minimal thunk
+
+ Not specifying this option is equivalent to
+ spectre_v2=auto.
+
spia_io_base= [HW,MTD]
spia_fio_base=
spia_pedr=
diff --git a/Documentation/x86/pti.txt b/Documentation/x86/pti.txt
new file mode 100644
index 000000000000..d11eff61fc9a
--- /dev/null
+++ b/Documentation/x86/pti.txt
@@ -0,0 +1,186 @@
+Overview
+========
+
+Page Table Isolation (pti, previously known as KAISER[1]) is a
+countermeasure against attacks on the shared user/kernel address
+space such as the "Meltdown" approach[2].
+
+To mitigate this class of attacks, we create an independent set of
+page tables for use only when running userspace applications. When
+the kernel is entered via syscalls, interrupts or exceptions, the
+page tables are switched to the full "kernel" copy. When the system
+switches back to user mode, the user copy is used again.
+
+The userspace page tables contain only a minimal amount of kernel
+data: only what is needed to enter/exit the kernel such as the
+entry/exit functions themselves and the interrupt descriptor table
+(IDT). There are a few strictly unnecessary things that get mapped
+such as the first C function when entering an interrupt (see
+comments in pti.c).
+
+This approach helps to ensure that side-channel attacks leveraging
+the paging structures do not function when PTI is enabled. It can be
+enabled by setting CONFIG_PAGE_TABLE_ISOLATION=y at compile time.
+Once enabled at compile-time, it can be disabled at boot with the
+'nopti' or 'pti=' kernel parameters (see kernel-parameters.txt).
+
+Page Table Management
+=====================
+
+When PTI is enabled, the kernel manages two sets of page tables.
+The first set is very similar to the single set which is present in
+kernels without PTI. This includes a complete mapping of userspace
+that the kernel can use for things like copy_to_user().
+
+Although _complete_, the user portion of the kernel page tables is
+crippled by setting the NX bit in the top level. This ensures
+that any missed kernel->user CR3 switch will immediately crash
+userspace upon executing its first instruction.
+
+The userspace page tables map only the kernel data needed to enter
+and exit the kernel. This data is entirely contained in the 'struct
+cpu_entry_area' structure which is placed in the fixmap which gives
+each CPU's copy of the area a compile-time-fixed virtual address.
+
+For new userspace mappings, the kernel makes the entries in its
+page tables like normal. The only difference is when the kernel
+makes entries in the top (PGD) level. In addition to setting the
+entry in the main kernel PGD, a copy of the entry is made in the
+userspace page tables' PGD.
+
+This sharing at the PGD level also inherently shares all the lower
+layers of the page tables. This leaves a single, shared set of
+userspace page tables to manage. One PTE to lock, one set of
+accessed bits, dirty bits, etc...
+
+Overhead
+========
+
+Protection against side-channel attacks is important. But,
+this protection comes at a cost:
+
+1. Increased Memory Use
+ a. Each process now needs an order-1 PGD instead of order-0.
+ (Consumes an additional 4k per process).
+ b. The 'cpu_entry_area' structure must be 2MB in size and 2MB
+ aligned so that it can be mapped by setting a single PMD
+ entry. This consumes nearly 2MB of RAM once the kernel
+ is decompressed, but no space in the kernel image itself.
+
+2. Runtime Cost
+ a. CR3 manipulation to switch between the page table copies
+ must be done at interrupt, syscall, and exception entry
+ and exit (it can be skipped when the kernel is interrupted,
+ though.) Moves to CR3 are on the order of a hundred
+ cycles, and are required at every entry and exit.
+ b. A "trampoline" must be used for SYSCALL entry. This
+ trampoline depends on a smaller set of resources than the
+ non-PTI SYSCALL entry code, so requires mapping fewer
+ things into the userspace page tables. The downside is
+ that stacks must be switched at entry time.
+ d. Global pages are disabled for all kernel structures not
+ mapped into both kernel and userspace page tables. This
+ feature of the MMU allows different processes to share TLB
+ entries mapping the kernel. Losing the feature means more
+ TLB misses after a context switch. The actual loss of
+ performance is very small, however, never exceeding 1%.
+ d. Process Context IDentifiers (PCID) is a CPU feature that
+ allows us to skip flushing the entire TLB when switching page
+ tables by setting a special bit in CR3 when the page tables
+ are changed. This makes switching the page tables (at context
+ switch, or kernel entry/exit) cheaper. But, on systems with
+ PCID support, the context switch code must flush both the user
+ and kernel entries out of the TLB. The user PCID TLB flush is
+ deferred until the exit to userspace, minimizing the cost.
+ See intel.com/sdm for the gory PCID/INVPCID details.
+ e. The userspace page tables must be populated for each new
+ process. Even without PTI, the shared kernel mappings
+ are created by copying top-level (PGD) entries into each
+ new process. But, with PTI, there are now *two* kernel
+ mappings: one in the kernel page tables that maps everything
+ and one for the entry/exit structures. At fork(), we need to
+ copy both.
+ f. In addition to the fork()-time copying, there must also
+ be an update to the userspace PGD any time a set_pgd() is done
+ on a PGD used to map userspace. This ensures that the kernel
+ and userspace copies always map the same userspace
+ memory.
+ g. On systems without PCID support, each CR3 write flushes
+ the entire TLB. That means that each syscall, interrupt
+ or exception flushes the TLB.
+ h. INVPCID is a TLB-flushing instruction which allows flushing
+ of TLB entries for non-current PCIDs. Some systems support
+ PCIDs, but do not support INVPCID. On these systems, addresses
+ can only be flushed from the TLB for the current PCID. When
+ flushing a kernel address, we need to flush all PCIDs, so a
+ single kernel address flush will require a TLB-flushing CR3
+ write upon the next use of every PCID.
+
+Possible Future Work
+====================
+1. We can be more careful about not actually writing to CR3
+ unless its value is actually changed.
+2. Allow PTI to be enabled/disabled at runtime in addition to the
+ boot-time switching.
+
+Testing
+========
+
+To test stability of PTI, the following test procedure is recommended,
+ideally doing all of these in parallel:
+
+1. Set CONFIG_DEBUG_ENTRY=y
+2. Run several copies of all of the tools/testing/selftests/x86/ tests
+ (excluding MPX and protection_keys) in a loop on multiple CPUs for
+ several minutes. These tests frequently uncover corner cases in the
+ kernel entry code. In general, old kernels might cause these tests
+ themselves to crash, but they should never crash the kernel.
+3. Run the 'perf' tool in a mode (top or record) that generates many
+ frequent performance monitoring non-maskable interrupts (see "NMI"
+ in /proc/interrupts). This exercises the NMI entry/exit code which
+ is known to trigger bugs in code paths that did not expect to be
+ interrupted, including nested NMIs. Using "-c" boosts the rate of
+ NMIs, and using two -c with separate counters encourages nested NMIs
+ and less deterministic behavior.
+
+ while true; do perf record -c 10000 -e instructions,cycles -a sleep 10; done
+
+4. Launch a KVM virtual machine.
+5. Run 32-bit binaries on systems supporting the SYSCALL instruction.
+ This has been a lightly-tested code path and needs extra scrutiny.
+
+Debugging
+=========
+
+Bugs in PTI cause a few different signatures of crashes
+that are worth noting here.
+
+ * Failures of the selftests/x86 code. Usually a bug in one of the
+ more obscure corners of entry_64.S
+ * Crashes in early boot, especially around CPU bringup. Bugs
+ in the trampoline code or mappings cause these.
+ * Crashes at the first interrupt. Caused by bugs in entry_64.S,
+ like screwing up a page table switch. Also caused by
+ incorrectly mapping the IRQ handler entry code.
+ * Crashes at the first NMI. The NMI code is separate from main
+ interrupt handlers and can have bugs that do not affect
+ normal interrupts. Also caused by incorrectly mapping NMI
+ code. NMIs that interrupt the entry code must be very
+ careful and can be the cause of crashes that show up when
+ running perf.
+ * Kernel crashes at the first exit to userspace. entry_64.S
+ bugs, or failing to map some of the exit code.
+ * Crashes at first interrupt that interrupts userspace. The paths
+ in entry_64.S that return to userspace are sometimes separate
+ from the ones that return to the kernel.
+ * Double faults: overflowing the kernel stack because of page
+ faults upon page faults. Caused by touching non-pti-mapped
+ data in the entry code, or forgetting to switch to kernel
+ CR3 before calling into C functions which are not pti-mapped.
+ * Userspace segfaults early in boot, sometimes manifesting
+ as mount(8) failing to mount the rootfs. These have
+ tended to be TLB invalidation issues. Usually invalidating
+ the wrong PCID, or otherwise missing an invalidation.
如果您对程序员文档有任何疑问，请在下面发表评论，我会尽力回答。
2018 年 1 月 16 日更新 Spectre 4.14.14 和 4.9.77
4.14.14如果您已经像我一样运行了内核版本 4.14.13 或 4.9.76，那么安装它并4.9.77在接下来的几天内发布以缓解 Spectre 安全漏洞是轻而易举的事。此修复程序的名称是雷特波林并没有像之前猜测的那样严重影响性能：
Greg Kroah-Hartman 已发送了 Linux 4.9 和 4.14 版本的最新补丁，其中现在包括 Retpoline 支持。
此 X86_FEATURE_RETPOLINE 适用于所有 AMD/Intel CPU。要获得全面支持，您还需要使用包含 -mindirect-branch=thunk-extern 支持的较新 GCC 编译器构建内核。GCC 更改已于昨天在 GCC 8.0 中发布，并且正在可能向后移植到 GCC 7.3。
那些想要禁用 Retpoline 支持的人可以使用以下命令启动修补的内核诺雷托林。
2018 年 1 月 12 日更新
初步保护来自幽灵已经推出并将在未来几周和几个月内得到改进。
Linux 内核 4.14.13、4.9.76 LTS 和 4.4.111 LTS
由此Softpedia 文章：
Linux 内核 4.14.13、4.9.76 LTS 和 4.4.111 LTS 现在可以从 kernel.org 下载，它们包含针对 Spectre 安全漏洞的更多修复，以及对上周发布的 Linux 4.14.12、4.9.75 LTS 和 4.4.110 LTS 内核的一些回归，因为有些内核报告了一些小问题。
这些问题现在似乎已经得到修复，因此可以安全地将基于 Linux 的操作系统更新到今天发布的新内核版本，其中包括更多 x86 更新、一些 PA-RISC、s390 和 PowerPC（PPC）修复、各种驱动程序改进（Intel i915、crypto、IOMMU、MTD）以及常见的 mm 和核心内核更改。
许多用户在 2018 年 1 月 4 日和 2018 年 1 月 10 日的 Ubuntu LTS 更新中遇到了问题。不过我已经使用了4.14.13几天，没有任何问题年龄变化率。跳至底部查看有关安装内核 14.14.13 的说明。
2018 年 1 月 7 日更新
格雷格·克罗哈特曼写了状态更新昨天，他谈到了 Meltdown 和 Spectre Linux 内核安全漏洞。有人可能会称他为 Linux 世界中仅次于 Linus 的第二大权势人物。本文讨论了稳定内核（如下所述）和大多数 Ubuntu 使用的 LTS 内核。
不推荐普通 Ubuntu 用户使用
此方法需要手动安装最新的主线（稳定）内核，不建议普通 Ubuntu 用户使用。原因是，手动安装稳定内核后，它会一直保留，直到您手动安装较新（或较旧）的内核。普通 Ubuntu 用户使用的是 LTS 分支，它将自动安装新内核。
正如其他人提到的，等待 Ubuntu 内核团队通过常规流程推出更新更为简单。
此答案适用于希望立即修复“Meltdown”安全问题并愿意做额外手动工作的高级 Ubuntu 用户。
Linux 内核 4.14.11、4.9.74、4.4.109、3.16.52 和 3.2.97 补丁 Meltdown 缺陷
从本文：
敦促用户立即更新系统
2018 年 1 月 4 日 01:42 GMT · 作者：Marius Nestor
Linux 内核维护者 Greg Kroah-Hartman 和 Ben Hutchings 发布了 Linux 4.14、4.9、4.4、3.16、3.18 和 3.12 LTS（长期支持）内核系列的新版本，显然修补了影响大多数现代处理器的两个关键安全漏洞之一。
Linux 4.14.11、4.9.74、4.4.109、3.16.52、3.18.91 和 3.2.97 内核现在可从 kernel.org 网站下载，如果用户运行任何这些内核系列，则建议立即将其 GNU/Linux 发行版更新到这些新版本。为什么要更新？因为它们显然修补了一个名为 Meltdown 的严重漏洞。
正如之前报道的那样，Meltdown 和 Spectre 是影响过去 25 年发布的几乎所有现代处理器 (CPU) 的设备的两个漏洞。是的，这意味着几乎所有的手机和个人电脑。未经授权的攻击者可以利用 Meltdown 恶意获取存储在内核内存中的敏感信息。
Spectre 漏洞补丁仍在开发中
Meltdown 是一个严重的漏洞，可能会泄露您的秘密数据，包括密码和加密密钥，而 Spectre 则更糟糕，而且很难修复。安全研究人员表示，它将困扰我们很长一段时间。众所周知，Spectre 利用了现代 CPU 用来优化性能的推测执行技术。
在 Spectre 漏洞得到修补之前，强烈建议您至少将 GNU/Linux 发行版更新到任何新发布的 Linux 内核版本。因此，请在您最喜欢的发行版的软件存储库中搜索新的内核更新并尽快安装。不要等到为时已晚，现在就行动吧！
我已经使用内核 4.14.10 一周了，因此下载并启动了 Ubuntu 主线内核版本4.14.11我并不太担心。
Ubuntu 16.04 用户可能更喜欢与 4.14.11 同时发布的 4.4.109 或 4.9.74 内核版本。
如果您的常规更新没有安装您想要的内核版本，您可以按照以下 Ask Ubuntu 答案手动进行安装：如何将内核更新到最新的主线版本？
4.14.12 - 一天的变化有多大
在我最初回答这个问题后不到 24 小时，他们就发布了一个补丁来修复 4.14.11 内核版本，他们可能匆忙发布了这个补丁。升级到4.14.12建议所有 4.14.11 用户使用。Greg-KH 说：
我宣布发布 4.14.12 内核。
所有4.14内核系列的用户都必须升级。
此版本中仍存在一些小问题，人们已经遇到了这些问题。希望这些问题能在本周末得到解决，因为补丁尚未进入 Linus 的版本树。
现在，与往常一样，请测试您的环境。
查看此更新，源代码没有改变太多行。
内核 4.14.13 安装
Linux Kernels 4.14.13、4.9.76 和 4.4.111 中引入了更多 Meltdown 修订版和 Spectre 功能。
您需要安装最新主线内核的原因如下：
- Ubuntu LTS 内核更新中的一个 bug
- 您有当前 Ubuntu LTS 内核更新流不支持的新硬件
- 您需要仅在最新主线内核版本中可用的安全升级或新功能。
截至 2018 年 1 月 15 日，最新的稳定主线内核是4.14.13。如果您选择手动安装，您应该知道：
- 较旧的 LTS 内核不会获取更新直到它们大于主菜单第一个选项标题Ubuntu。
- 手动安装的内核不能通过常规
sudo apt auto-remove命令删除。您需要遵循以下步骤：如何删除旧内核版本来清理启动菜单？ - 监控旧内核的发展情况，以便确定何时需要恢复常规 LTS 内核更新方法。然后删除手动安装的主线内核，如上一个要点链接中所述。
- 手动删除最新的主线内核后
sudo update-grub，运行 Ubuntu 的最新 LTS 内核将是第一个选项Ubuntu在 Grub 的主菜单上。
现在警告已经消除，要安装最新的主线内核（4.14.13）请点击以下链接：如何在没有任何发行版升级的情况下将内核更新到最新的主线版本？
