Red Hat 和 Oracle 的 Meltdown/Spectre 漏洞状态
Red Hat 操作系统系列在其 v3.10 内核中迅速解决了 Meltdown 和 Spectre 漏洞，但过度依赖英特尔存在缺陷的微代码，并被迫从完整的解决方案中回退。Oracle 实施了更适合其 v4.1 UEK 的替代方法，但由于都在等待英特尔，这两个内核仍然缺乏对 Spectre 的完全覆盖。谷歌的 retpoline 明显缺席于这两个 Linux 分支，它为所有 CPU 提供了更大且更高效的覆盖。审计此状态是一项挑战。本文介绍了最新的漏洞评估工具。
今年 Meltdown 和 Spectre CPU 漏洞披露引发了疯狂的补丁活动。通常安静的英特尔芯片微代码包在一月份看到了 四次 更新，其中一次最终是为了回滚触发随机重启的有缺陷的代码。对于企业级硬件，英特尔的质量控制还有很多不足之处。
现在部署新的监控和合规性工具可能为时过早，并且针对这组漏洞的最终解决方案将等到获得正确的微代码。尽管如此，对于许多组织来说，评估运行由 Oracle 和/或 Red Hat 打包的 Linux 内核的服务器的补丁状态可能很重要。
Meltdown 补丁现在已经存在，应该立即部署在易受攻击的服务器上。修复所有 Spectre 漏洞不仅需要最新的内核，还需要打过补丁的 GCC 来编译能够实现“retpolines”的内核，或者来自您的 CPU 供应商的兼容微代码。
RHCKRed Hat 是最早发布 关于 Meltdown 和 Spectre 指导 的 Linux 发行版之一。它在 /sys/kernel/debug/x86 目录中建立了三个文件作为“内核可调参数”，以监控和控制这些补丁：pti_enabled 用于 Meltdown，ibpb_enabled 用于 Spectre v1，ibrs_enabled 用于 Spectre v2。只有 root 用户才能访问这些文件。
当这些文件包含数字零时，补丁未激活。如果 CPU 允许，可以将数字一写入文件以启用相关的修复，稍后可以写入零以禁用它。这并非总是被允许——AMD 处理器不易受 Meltdown 影响，并且 pti_enabled 文件中的值被锁定为零且无法更改。如果修复程序处于活动状态并显示 1，则 CPU 的性能可能会降低。需要兼容的微代码才能在易受攻击的 CPU 上启用所有补丁，这会添加新的汇编器/机器语言操作码，以从 CPU 管道和缓存中擦除易受攻击的内核数据，从而关闭漏洞。
通常不为人所知的是，尽管 BIOS 负责提供基本微代码映像，但 Linux 内核能够在启动时使用英特尔微代码的易失性运行时升级来更新某些 CPU。更新必须来自 CPU 供应商，并带有其数字签名；它不能由操作系统维护人员独立生成。这在英特尔 CPU 上通过以下 RPM 完成（AMD CPU 的微代码包含在更大的“linux-firmware”软件包中）
# rpm -qi microcode_ctl
Name : microcode_ctl
Epoch : 2
Version : 2.1
Release : 22.5.0.3.el7_4
Architecture: x86_64
Install Date: Sun 21 Jan 2018 12:58:36 PM CST
Group : System Environment/Base
Size : 1001060
License : GPLv2+ and Redistributable, no modification permitted
Signature : RSA/SHA256, Sat 20 Jan 2018 08:32:03 PM CST, Key ID
72f97b74ec551f03
Source RPM : microcode_ctl-2.1-22.5.0.3.el7_4.src.rpm
Build Date : Sat 20 Jan 2018 08:31:55 PM CST
Build Host : x86-ol7-builder-02.us.oracle.com
Relocations : (not relocatable)
Vendor : Oracle America
URL : http://fedorahosted.org/microcode_ctl
Summary : Tool to transform and deploy CPU microcode update for x86.
Description :
The microcode_ctl utility is a companion to the microcode driver written
by Tigran Aivazian <tigran@aivazian.fsnet.co.uk>.
The microcode update is volatile and needs to be uploaded on each system
boot i.e. it doesn't reflash your cpu permanently, reboot and it reverts
back to the old microcode.
Red Hat “推卸责任” 了英特尔最近有缺陷的微代码，回退到以前的软件包，并建议客户获取 BIOS 更新以修复 Spectre 漏洞。尽管 Red Hat 很可能在遥远的将来再次发布新的英特尔微代码更新，但显然存在 挫败感，这可能会延迟完全的安全合规性。
UEKOracle 将 Unbreakable Enterprise Kernel (UEK) 作为其推荐的 Linux 发行版。在其发行版中使用时，它追溯性地重命名了 Red Hat-Compatible Kernel (RHCK)，现在 RHCK 包含 /sys/kernel/debug/x86 中的文件。
UEK 是企业 Linux 中的热门选择，它为 RPM 发行版带来了许多新功能。它是以受支持的方式在 Red Hat 衍生操作系统（通常最多运行 v3.10）中实施 v4.1 性能调优内核的最简单和最稳定的方法。
UEK 尤其值得注意，因为它与 Ksplice（RHCK 也是如此）配合使用，允许在线内核补丁和升级而无需重启，甚至可以将此功能扩展到选定的用户空间库（glibc 和 OpenSSL）。这项服务免费提供给 Fedora 和 Ubuntu 用户，并作为 CentOS（在脚本化转换为 Oracle Linux 后）和 Red Hat 的付费支持选项。Ksplice 是 Linux 安全升级最古老和最成熟的高可用性选项。
UEK 实施了一组不同的世界可读监控文件，并且它们似乎不允许调整。这通常不为人所知（该信息来自 Oracle 支持）。
Oracle 建议您可以从以下位置了解正在运行的 UEK 下的 Meltdown 和 Spectre 状态
# awk '{print FILENAME":"$0}' /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable
UEK 还向 /proc/cpuinfo 添加了关于正在运行的 CPU 的错误状态的注释（在 RHCK 上启动时不会出现）
# egrep '(model name|bugs)' /proc/cpuinfo | sort -u
bugs : cpu_meltdown spectre_v2
model name : Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz
Oracle 进一步建议查阅文档 ID 2348448.1 以获得关于 Linux 下 Meltdown 和 Spectre 修复的完整详细信息。Oracle Solaris 也容易受到攻击，并在最新的 关键补丁更新 中得到解决。请注意，由于需要更新的微代码才能修复受支持的英特尔 CPU 上的 Spectre 漏洞，即使对于使用 Ksplice 的系统，也需要重启。
脚本Stephane Lesimple 在 Github 上发布了一个详细的检测脚本。该脚本是一个杰作，可以测试所有已知的缓解措施和微代码。最新版本现在（主要）能够正确检测 UEK，并且具有 JSON 和 NRPE 的输出选项。这很可能在不久的将来仍然是 Linux 上投机攻击的权威审计工具。
Lesimple 的脚本还探测内核中是否存在“retpolines”。Retpolines 涉及 CPU 的“间接寻址模式”，当寄存器参与计算分支目标（通常提到“跳转表”）时。retpoline 本质上为内核二进制文件中每个易受攻击的跳转执行 Spectre 漏洞利用，并且需要有能力的编译器来实现它。即使在较旧的微代码上运行，实现 retpolines 的 Linux 内核也不会受到 Spectre 的攻击，并且保持对推测执行的完全控制。性能影响已被 证明远不如 在英特尔自己的 Clear Linux 发行版上使用微代码修复的内核那么剧烈。
谷歌（开发并引入了这个概念）已将 retpolines 推送到 Android 的 1 月份安全公告中，并在其数据中心部署了启用 retpoline 的内核。retpolines 可能还需要一段时间才能开始出现在受支持的 Nexus 和 Pixel 设备之外——LineageOS（以其快速推送补丁而闻名）目前只有一个设备具有启用 retpoline 的内核。
不幸的是，UEK 和 RHCK 目前似乎都不支持 retpoline。向旧版 GCC 反向移植的努力似乎是一个障碍。
无论如何，以下是在各种架构上运行 Lesimple 脚本的演示。首先是在第一个 Meltdown 感知的 RHCK 上使用第一个 1 月份微代码版本的 Oracle Linux 系统。您可以从 RHCK 可调参数中看到所有补丁都已激活
# for x in /sys/kernel/debug/x86/*_enabled; do echo "$x:$(<$x)"; done
/sys/kernel/debug/x86/ibpb_enabled:1
/sys/kernel/debug/x86/ibrs_enabled:1
/sys/kernel/debug/x86/pti_enabled:1
该脚本警告说微代码不稳定，但确认系统（主要）已打补丁——它没有检测到 Spectre V1 修复
# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.34
Checking for vulnerabilities on current system
Kernel is Linux 3.10.0-693.11.6.el7.x86_64 #1 SMP Wed Jan 3 18:59:47
↪PST 2018 x86_64
CPU is Intel(R) Pentium(R) CPU G3220T @ 2.60GHz
We're missing some kernel info (see -v), accuracy might be reduced
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: YES
* CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: YES
* CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: YES
* CPU indicates STIBP capability: YES
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown
↪(RDCL_NO): NO
* CPU microcode is known to cause stability problems: YES (model 60
* stepping 3 ucode 0x23)
The microcode your CPU is running on is known to cause instability
↪problems, such as intempestive reboots or random crashes.
You are advised to either revert to a previous microcode version
↪(that might not have the mitigations for Spectre), or
↪upgrade to a newer one if available.
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Kernel has array_index_mask_nospec: UNKNOWN (couldn't check (couldn't
* find your kernel image in /boot, if you used netboot, this is normal))
* Checking count of LFENCE instructions following a jump in kernel:
* UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if
* you used netboot, this is normal))
> STATUS: UNKNOWN (Couldn't find kernel image or tools missing to
> execute the checks)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: YES
* Currently enabled features
* IBRS enabled for Kernel space: YES
* IBRS enabled for User space: NO
* IBPB enabled: YES
* Mitigation 2
* Kernel compiled with retpoline option: UNKNOWN (couldn't read
* your kernel configuration)
* Kernel compiled with a retpoline-aware compiler: NO
* Retpoline enabled: NO
> STATUS: NOT VULNERABLE (IBRS/IBPB are mitigating the vulnerability)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
A false sense of security is worse than no security at all,
↪see --disclaimer
在 UEK 下运行最新版本的脚本现在产生了合理的结果。UEK 文件在脚本中被特别提及，并重复以下评论：# 此内核具有 /sys 接口，信任它胜过一切。以下是结果
# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.34
Checking for vulnerabilities on current system
Kernel is Linux 4.1.12-112.14.13.el7uek.x86_64 #2 SMP Thu Jan 18
↪11:38:29 PST 2018 x86_64
CPU is Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown
↪(RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO (model 15
* stepping 13 ucode 0xa4)
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (kernel confirms
* that your CPU is unaffected)
* Kernel has array_index_mask_nospec: NO
* Checking count of LFENCE instructions following a jump in kernel:
↪YES (34
* jump-then-lfence instructions found, which is >= 30 (heuristic))
> STATUS: NOT VULNERABLE (Not affected)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: NO (kernel confirms your
* system is vulnerable)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: YES
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: UNKNOWN
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
* Retpoline enabled: NO
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with
> retpoline are needed to mitigate the vulnerability)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms
* that the mitigation is active)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)
A false sense of security is worse than no security at all,
↪see --disclaimer
请注意，UEK 的 Spectre V1 修复是通过 jump-then-lfence 指令的“启发式”计数检测到的；希望这是可靠的。
对于操作系统内核供应商来说，重要的是要了解用户社区希望以最小的性能和稳定性损失获得这些安全修复程序。英特尔的微代码更新未能满足这一要求，现在由操作系统维护人员来关闭漏洞。应该继续向英特尔提出问题，询问为什么会出现有缺陷的固件，为什么它比 retpolines 慢，以及重新设计的微代码解决方案如何改进 retpoline 性能。从性能的角度来看，实际上没有任何东西比英特尔一月份的努力更可取。
但是，如果 Red Hat 继续声称它已“推卸责任”，那么 Oracle 显然有机会将启用 retpoline 的 UEK 确立为用户社区中广泛采用的选择。尽管人们希望所有供应商都能关注并响应其用户，但如果将 retpolines 添加到 UEK 已经相当大的优势中，UEK 将在 RPM 世界中成为一个更加引人注目和强大的选择。即使是（明确标记的）beta 测试版本也会在这方面取得很大进展。
可以肯定的是，这个故事远未结束。合适的人尚未发声，合适的言语尚未说出。希望它能迅速而圆满地结束。
免责声明本文中表达的观点和意见仅代表作者个人，不一定反映 Linux Journal 的观点。
Charles Fisher 拥有爱荷华大学电气工程学位，并在一家财富 500 强矿业和制造公司担任系统和数据库管理员。
