什么是Ubuntu在Meltdown和Spectre漏洞上的状态？
任何与状态更新有关的问题，或者询问是否要修补这些漏洞的任何问题都应该作为此问题的副本关闭。
Meltdown和Spectre现在在新闻中，声音非常严重。 我没有看到任何来自Ubuntu的安全更新来涵盖这些漏洞。
什么是Ubuntu对这些漏洞的处理，以及Ubuntu用户应该做些什么？
这些是CVE-2017-5753，CVE-2017-5715和CVE-2017-5754。
据发现，一类新的侧信道攻击会影响大多数处理器，包括Intel，AMD和ARM的处理器。 该攻击允许恶意用户空间进程读取guest虚拟机中的内核内存和恶意代码以读取虚拟机管理程序内存。
要解决此问题，需要更新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）。
- 2018年1月22日在USN-3541-2 （Ubuntu 16.04 LTS（HWE））， USN-3540-1 （Ubuntu 16.04 LTS）上提供了进一步的内核更新（包括Spectre变体的缓解和Meltdown的其他缓解）。 ）， 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提供Intel微码更新。由于回归，微码更新现已恢复（ USN-3531-2 ）。
用户应以正常方式立即安装更新。 需要重新启动才能使内核和微代码更新生效。
用户可以在重新启动后validation内核页表隔离修补程序是否处于活动状
Ubuntu 17.04（Zesty Zapus）的更新将不会提供，因为它已于2018年1月13日达到使用寿命 。
在发布安全更新之前，Dustin Kirkland已经提供了一些博客文章中更多详细信息，包括内核更新以及CPU微代码，gcc和qemu更新。
Canonical的Kiko Reis在2018年1月24日写了一篇关于这些漏洞及其缓解对Ubuntu用户的影响的可访问描述 。
Ubuntu安全团队正在维护他们在这些问题上的现状以及官方技术常见问题解答 ，详细介绍了特定的个人漏洞变体及其在不同用例下的迁移。
这里有一些具体的事情需要记住，这是从我不仅仅是Ubuntu的一些分析和安全邮件列表中获取的：
-
Meltdown攻击可以在内核级别进行修补。 这将有助于防止Meltdown漏洞集。
-
幽灵攻击向量更难以防范，但对于坏人来说也更难以利用。 虽然有已知攻击向量的软件补丁，例如可以修补的LLVM攻击向量，但核心问题是要真正修复幽灵，你必须改变CPU硬件的工作和行为方式。 这使得保护更加困难，因为只有已知的攻击向量才能被修补。 然而，每个软件都需要针对这个问题进行单独强化，这意味着它是“一个补丁不能解决所有”交易的其中之一。
现在，对于大问题：
- Ubuntu会不会修补Meltdown和Spectre漏洞？
- 答案是肯定的 ，但这很棘手，补丁涓滴进入内核，但内核和安全团队在进行测试时可能会看到意外的回归，他们必须修补以解决意外问题。 安全和内核团队正在努力解决这个问题。
-
什么时候可以修复？
-
我将从内核团队那里得到相同的答案：“当我们确信补丁有效时，我们不会在此过程中突破其他任何问题。”
现在，需要考虑的一件大事：1月9日有一个公开披露的目标日期，这应该与修复版本一致。 然而，披露发生在1月3日，而不是。 内核团队和安全团队仍然针对1月9日的日期， 但这不是一个确定的截止日期，如果内核的任何重要内容在此过程中中断，可能会有延迟
-
-
有什么地方我应该在Meltdown和Spectre上寻找更多更新吗？
-
是的，实际上。 Ubuntu安全团队有一篇关于Spectre和Meltdown的知识库文章，你可以在这里看到一些状态报告，这些报告关于修复程序的发布时间表和不发布的时间表。
您还应该观看Ubuntu安全团队的安全通知站点，并留意内核可用的修复程序的公告。
-
您应该关注的其他相关链接：
- 熔毁和幽灵 – 信息网站
- Ubuntu安全团队知识库 – 幽灵和崩溃
- Ubuntu CVE Tracker – Meltdown – CVE-2017-5754
- Ubuntu CVE Tracker – Spectre – 1 of 2 – CVE-2017-5715
- Ubuntu CVE Tracker – Spectre – 2 of 2 – CVE-2017-5753
2018年1月20日
Linux内核团队于2018年1月15日发布了针对内核4.9.77和4.14.14的幽灵保护（ Retpoline ）.Ubuntu内核团队仅在2018年1月17日发布内核版本4.9.77并且尚未发布内核版本4.14 0.14。 原因尚不清楚为什么但在Ask Ubuntu中已经重新请求了4.14.14 ： 为什么内核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 +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日更新Specter在4.14.14和4.9.77
如果您已经在运行内核版本4.14.13或4.9.76，那么安装4.14.14和4.9.77时，如果它们在几天后出来以缓解Spectre安全漏洞则是4.9.77 。 这个修复程序的名称是Retpoline ，它没有以前推测的严重性能损失 ：
Greg Kroah-Hartman已经发布了针对Linux 4.9和4.14版本的最新补丁，现在包括Retpoline支持。
所有AMD / Intel CPU都启用了X86_FEATURE_RETPOLINE。 要获得完全支持，您还需要使用包含-mindirect-branch = thunk-extern支持的较新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，它们包含针对Specter安全漏洞的更多修复，以及来自Linux 4.14.12,4.9的一些回归上周发布了.75 LTS和4.4.110 LTS内核，因为有些报道了一些小问题。
这些问题现在似乎已得到解决，因此将基于Linux的操作系统更新为今天发布的新内核版本是安全的，其中包括更多x86更新，一些PA-RISC，s390和PowerPC（PPC）修复，以及对驱动程序（Intel i915，加密，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内核安全漏洞的状态更新 。 有些人可能称他为Linus旁边Linux世界中第二强大的人。 本文讨论了大多数Ubuntu使用的稳定内核（下面讨论过）和LTS内核。
不建议普通Ubuntu用户使用
此方法涉及手动安装最新的主线（稳定）内核，不建议普通的Ubuntu用户使用。 原因是在您手动安装稳定内核后，它会一直保留在那里，直到您手动安装较新的（或更旧的）内核。 平均Ubuntu用户位于LTS分支上，该分支将自动安装新内核。
正如其他人所提到的，等待Ubuntu内核团队通过常规流程推出更新更为简单。
这个答案适用于希望立即修复“熔毁”安全性并愿意做额外手动工作的高级Ubuntu用户。
Linux内核4.14.11,4.9.74,4.4.109,3.16.52和3.2.97补丁崩溃缺陷
从这篇文章 ：
敦促用户立即更新他们的系统
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（长期支持）内核系列的新版本，显然修补了影响最现代化的两个关键安全漏洞之一处理器。
现在可以从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恶意获取存储在内核内存中的敏感信息。
Patch for Spectre漏洞仍在进行中
虽然Meltdown是一个严重的漏洞，可能会暴露您的秘密数据，包括密码和加密密钥，但Spectre更糟糕，而且修复起来并不容易。 安全研究人员表示，它将困扰我们很长一段时间。 众所周知，Spectre利用现代CPU使用的推测性执行技术来优化性能。
在修补Spectre bug之前，强烈建议您至少将GNU / Linux发行版更新到任何新发布的Linux内核版本。 因此，请搜索您喜欢的发行版的软件存储库以获取新的内核更新，并尽快安装它。 不要等到为时已晚，立即行动吧！
我一直使用内核4.14.10一周，所以下载和启动Ubuntu Mainline内核版本4.14.11对我来说并不是一个太大的问题。
Ubuntu 16.04用户可能更熟悉4.4.109或4.9.74内核版本，它们与4.14.11同时发布。
如果你的常规更新没有安装你想要的内核版本，你可以按照这个问题Ubuntu的答案手动完成： 如何将内核更新到最新的主线版本？
4.14.12 – 一天有什么不同
在我的初步回答后不到24小时，发布了一个补丁来修复4.14.11内核版本，他们可能已经冲出去。 建议所有4.14.11用户升级到4.14.12 。 Greg-KH说 ：
我宣布发布4.14.12内核。
4.14内核系列的所有用户都必须升级。
此版本中仍然存在一些人们遇到过的小问题。 希望他们将在本周末得到解决，因为补丁没有落在Linus的树上。
就目前而言，请一如既往地测试您的环境。
查看此更新并未更改很多源代码行。
内核4.14.13安装
Linux内核4.14.13,4.9.76和4.4.111中引入了更多Meltdown版本和Spectrefunction的开头。
您有理由想要安装最新的主线内核：
- 上一次Ubuntu LTS内核更新中的一个错误
- 您当前的Ubuntu LTS内核更新流中不支持新硬件
- 您希望仅在最新的主线内核版本中提供安全性升级或新function。
截至2018年1月15日，最新的稳定主线内核为4.14.13 。 如果您选择手动安装它，您应该知道：
- 较旧的LTS内核在大于标题为Ubuntu的主菜单第一个选项之前不会更新 。
- 使用通常的
sudo apt auto-remove命令不会删除手动安装的内核。 您需要遵循以下步骤： 如何删除旧内核版本以清理启动菜单？ - 当您想要恢复常规LTS内核更新方法时，监视旧内核中的开发。 然后删除手动安装的主线内核，如上一个项目符号链接中所述。
- 在手动删除最新的主线内核之后运行
sudo update-grub，然后Ubuntu的最新LTS内核将成为Grub主菜单上第一个名为Ubuntu的选项。
现在警告已经完成，安装最新的主线内核（ 4.14.13 ）请点击此链接： 如何在没有任何Distro-upgrade的情况下将内核更新到最新的主线版本？
