一月20，2018
Linux内核团队于2018年1月15日针对内核4.9.77和4.14.14发布了Spectre保护（Retpoline）。Ubuntu内核团队仅于2018年1月17日发布了内核版本4.9.77，但未发布内核版本4.14。 .14。原因尚不清楚，为什么要重新请求4.14.14，如“问Ubuntu”中的回答：为什么发布了4.9.77内核而不发布4.14.14内核？直到今天才出现。
2018年1月17日为融化添加Spectre支持
我认为有些人会对4.14.14（从4.14.13开始）中的更改感兴趣，这些变化记录在程序员的评论中，我认为从我的有限接触来看，对于内核C程序员而言，它相当详细。以下是从4.14.13到4.14.14内核的更改，主要针对Spectre支持：
+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 <linux-kernel@vger.kernel.org>
+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日更新了4.14.14和4.9.77中的Spectre
如果您已经在运行像我这样的内核版本4.14.13或4.9.76，那么安装它就很容易了，4.14.14并且4.9.77几天之内发布它们来缓解Spectre安全漏洞。此修复程序的名称是Retpoline，它没有先前推测的严重性能下降：
Greg Kroah-Hartman发送了针对Linux 4.9和4.14点发行版的最新补丁，其中包括Retpoline支持。
所有AMD / Intel CPU都启用了X86_FEATURE_RETPOLINE。为了获得全面支持，您还需要使用包含-mindirect-branch = thunk-extern支持的更新的GCC编译器来构建内核。GCC变更已于昨天在GCC 8.0中发布，并且有可能被反向移植到GCC 7.3中。
那些想要禁用Retpoline支持的用户可以使用noretpoline引导修补的内核。
2018年1月12日更新
来自Spectre的初始保护已经到来，并将在数周和数月内得到改善。
Linux内核4.14.13、4.9.76 LTS和4.4.111 LTS
从Softpedia的这篇文章中：
现在可以从kernel.org下载Linux内核4.14.13、4.9.76 LTS和4.4.111 LTS，它们包括针对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了几天，没有任何问题，但是YMMV。跳至底部，获取有关安装内核14.14.13的说明。
2018年1月7日更新
Greg Kroah-Hartman昨天在Meltdown和Spectre Linux Kernel安全漏洞上写了状态更新。有人可能称他为Linux上仅次于Linus的第二大人物。本文介绍了大多数Ubuntu使用的稳定内核（下面讨论）和LTS内核。
不建议一般的Ubuntu用户使用
该方法涉及手动安装最新的主线（稳定）内核，不建议一般的Ubuntu用户使用。原因是在您手动安装稳定的内核之后，该问题会一直存在，直到您手动安装更新（或更旧）的内核为止。普通的Ubuntu用户在LTS分支上，该分支将自动安装新内核。
正如其他人提到的那样，等待Ubuntu Kernel Team通过常规过程推出更新更为简单。
此答案适用于想要立即修复“ Meltdown”安全性并愿意做额外的手动工作的高级Ubuntu用户。
Linux内核4.14.11、4.9.74、4.4.109、3.16.52和3.2.97修补程序崩溃缺陷
从这篇文章：
敦促用户立即更新其系统
2018年1月4日，格林尼治标准时间·Marius Nestor
Linux内核维护者Greg Kroah-Hartman和Ben Hutchings发布了Linux 4.14、4.9、4.4、3.16、3.18和3.12 LTS（长期支持）内核系列的新版本，这些系列显然修补了影响最现代的两个关键安全漏洞之一。处理器。
现在可以从kernel.org网站下载Linux 4.14.11、4.9.74、4.4.109、3.16.52、3.18.91和3.2.97内核，并敦促用户更新其GNU / Linux发行版如果这些新版本可以立即运行这些内核系列中的任何一个，则可以使用它们。为什么要更新？因为它们显然修补了称为Meltdown的严重漏洞。
如前所述，Meltdown和Spectre是两个漏洞，几乎影响了过去25年中发布的现代处理器（CPU）驱动的所有设备。是的，这意味着几乎所有的手机和个人计算机。非特权攻击者可以利用Meltdown恶意获取存储在内核内存中的敏感信息。
补丁幽灵漏洞仍在进行中
虽然Meltdown是一个严重的漏洞，可以泄露您的秘密数据，包括密码和加密密钥，但Spectre更为严重，而且不容易修复。安全研究人员说，它将困扰我们相当长的时间。众所周知，Spectre利用现代CPU使用的推测执行技术来优化性能。
在也修复了Spectre错误之前，强烈建议您至少将GNU / Linux发行版更新为任何新发行的Linux内核版本。因此，请在您喜欢的发行版的软件存储库中搜索新的内核更新，并尽快进行安装。不要等到为时已晚，现在就做！
我已经使用Kernel 4.14.10一周了，所以下载和引导Ubuntu Mainline Kernel版本4.14.11对我来说不是太大的问题。
Ubuntu 16.04用户可能更喜欢与4.14.11同时发布的4.4.109或4.9.74内核版本。
如果您的常规更新未安装您希望的内核版本，则可以按照以下Ubuntu答案手动进行操作：如何将内核更新为最新的主线版本？
4.14.12-一天有什么不同
在我最初回答后不到24小时内，发布了一个补丁程序来修复他们可能匆忙解决的4.14.11内核版本。建议所有4.14.11用户升级到4.14.12。格雷格-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内核更新中的错误
- 当前的Ubuntu LTS内核更新流中不支持新硬件
- 您需要仅在最新的主线内核版本中可用的安全升级或新功能。
截至2018年1月15日，最新的稳定主线内核为4.14.13。如果选择手动安装，则应了解：
- 较早的LTS内核要大于主菜单的第一个选项Ubuntu，才能被更新。
- 手动安装的内核不会用通常的
sudo apt auto-remove命令删除。您需要按照这样的：如何删除旧版本的内核来清理启动菜单？
- 监视旧内核的发展，以了解何时需要常规的LTS内核更新方法。然后按照上一个项目符号链接中的描述删除手动安装的主线内核。
- 在手动删除运行的最新主线内核之后
sudo update-grub，然后Ubuntu的最新LTS内核将成为Grub主菜单上名为Ubuntu的第一个选项。
既然警告已经消失，那么要安装最新的主线内核（4.14.13），请单击以下链接：如何在不进行任何发行版升级的情况下将内核更新为最新的主线版本？
