目前的Meltdown Intel处理器漏洞通过启用页面表隔离来解决。有个问题是如何关闭它: 如何关闭Page Table Isolation以恢复因Intel CPU安全补丁而导致的性能损失?
我的问题则相反:在运行中的系统上是否有一种方法可以检查PTI机制是否对系统有效,从而保护系统?我特别寻找cat /proc/something
或 cat /sys/something
的方式,而不是检查内核版本或配置参数等。
目前的Meltdown Intel处理器漏洞通过启用页面表隔离来解决。有个问题是如何关闭它: 如何关闭Page Table Isolation以恢复因Intel CPU安全补丁而导致的性能损失?
我的问题则相反:在运行中的系统上是否有一种方法可以检查PTI机制是否对系统有效,从而保护系统?我特别寻找cat /proc/something
或 cat /sys/something
的方式,而不是检查内核版本或配置参数等。
/proc/cpuinfo
来查看:
grep -q "cpu_insecure\|cpu_meltdown\|kaiser" /proc/cpuinfo && echo "已修复 :)" \
|| echo "未修复 :("
或者从 dmesg
命令中获取(感谢 Jason Creighton):
dmesg | grep -q "Kernel/User page tables isolation: enabled" \
&& echo "已修复 :)" || echo "未修复 :("
...
so far so good (i.e. meltdown safe) ...
System not affected (take it with a grain of salt though as false negative
may be reported for specific environments; Please consider running it once again).
使用https://github.com/speed47/spectre-meltdown-checker工具进行检查:
cd /tmp
wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
sudo sh /tmp/spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.27
Checking for vulnerabilities against live running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
...
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
dmesg | grep 'page tables isolation'
如果显示为启用,则 PTI 已启用。如果未显示任何内容或在终端中看到“禁用”,则 PTI 已禁用。Ubuntu 尚未发布此补丁,因此不会显示任何消息。
dmesg
输出中。如果/var/log/kern.log*
文件够早,可以查看其中是否包含启动消息。Ubuntu曾经将启动时的dmesg
输出记录到/var/log/dmesg
,但似乎不再这样做了。 - Peter Cordesdmesg: invalid option -- 'w'
的错误。-H
选项也是无效的。根据这个答案,移除这些选项对我来说解决了问题。 - wjandrea您可以通过运行cat /proc/cpuinfo
命令来检查,如果在“bugs”下报告了cpu_insecure
,则PTI已启用。
如果它是空白的(或者只是没有列出cpu_insecure
),那么很可能您正在运行尚未修补的内核(Ubuntu尚未修补),或者您有一个AMD处理器(对于这种情况,预计不会启用,因为它们不易受攻击)。
目前,在最新的4.15内核中所有CPU都被视为易受攻击。
cpu_insecure
;4.14.12及更高版本仅为英特尔CPU设置(包括那些过旧或过原始而不易受攻击的CPU)。即使KPTI被禁用,两者都会进行设置。 - Markbugs: cpu_meltdown spectre_v1 spectre_v2
,我不知道这是否意味着CPU容易受到它们的攻击,或者这些漏洞已经被发现并得到了缓解。 - Frédéric Grosshans$ cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTE Inversion
Mitigation: Clear CPU buffers; SMT vulnerable
Mitigation: PTI
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
Mitigation: usercopy/swapgs barriers and __user pointer sanitization
Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling
CONFIG_PAGE_TABLE_ISOLATION=y
,这意味着内核是使用KPTI编译的。$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz
CONFIG_PAGE_TABLE_ISOLATION=y
/proc/
目录中当前运行的内核配置是未启用的。不过,有一个(不太优雅的)解决方法是改为在/boot/config-$( uname -r )
中使用grep命令。 - blubberdiblubgrep CONFIG_PAGE_TABLE_ISOLATION /boot/config-$(uname -r)
CONFIG_PAGE_TABLE_ISOLATION=y
我进行了更新:
sudo apt-get update && sudo apt-get install linux-image-generic
sudo apt-get update
sudo apt-get dist-upgrade
uname -r
dmesg | grep isolation && echo "patched :)" || echo "unpatched :("
命令是不必要的危险:它没有显示实际匹配的行,而且如果随机匹配到其他"隔离"实例,也会愉快地打印出"patched :)"。 - Jaap Eldering/proc/cpuinfo
中使用grep命令查找cpu_insecure)。如果你将其放入脚本中,并且在未来的CPU中,该问题已经在其微架构中修复,那么/proc/cpuinfo
将不再显示cpu_insecure
,而你的脚本会错误地认为内核是未打补丁的,即使它实际上是已打补丁的。我也不建议采用第三个建议,因为很有可能在某个时刻dmesg
输出中会出现单词isolation
,而它并不一定指的是内核页表隔离。 - blubberdiblubisolation
的搜索时,会匹配到Kernel/User page tables isolation: enabled
和Kernel/User page tables isolation: disabled on command line
两个结果。 - MarkUbuntu 16.04.3
和4.4.0-108-generic
的正面信息。 - Seppo Erviälä/proc/cpuinfo
中检查"kaiser"标志是否足够?或者即使在启动时禁用了页面表隔离但编译进内核的情况下,我们仍然可以拥有这个标志吗? - Rmano16.04.3 LTS
4.4.0-109-generic
版本,前两个是“未修补”的,最后一个(dmesg)是“已修补”的。我应该相信哪一个? - Novagrep
命令显示为"Kernel/User page tables isolation: disabled"。与此同时,meltdown-checker
报告为"meltdown safe"。这意味着内核支持页面表隔离,但由于AMD CPU不易受到该攻击,因此被禁用了。 - rprcat /proc/cpuinfo | grep bugs
将显示类似以下内容:错误 : cpu_meltdown spectre_v1 spectre_v2
- Ahmed