65

The current Meltdown Intel processor vulnerability is currently remedied by having the page table isolation enabled. There is a question how to turn this off: How to disable Page Table Isolation to regain performance lost due to Intel CPU security hole patch?

My question is opposite: is there a way to check on a running system whether the PTI mechanism is effective on the system and thus the system is protected? I'm specifically looking for cat /proc/something or cat /sys/something, not checking for kernel version or config parameter or the like.

Braiam
  • 67,791
  • 32
  • 179
  • 269
Martin Vysny
  • 752

7 Answers7

63

  • Grepping CONFIG_PAGE_TABLE_ISOLATION in kernel config as Raniz's suggested does not help on desktop Ubuntu, but may help on cloud instances:

    grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && \
echo "patched :)" || echo "unpatched :("

  • You can check with /proc/cpuinfo as JonasCz suggested:

    grep -q "cpu_insecure\|cpu_meltdown\|kaiser" /proc/cpuinfo && echo "patched :)" \
|| echo "unpatched :("

  • Or from dmesg (thanks to Jason Creighton):

    dmesg | grep -q "Kernel/User page tables isolation: enabled" \
&& echo "patched :)" || echo "unpatched :("

  • You can compile test program from Raphael Carvalho for Meltdown detection:

    sudo apt-get install git build-essential
cd /tmp
git clone https://github.com/raphaelsc/Am-I-affected-by-Meltdown.git
cd Am-I-affected-by-Meltdown
make
sudo sh -c "echo 0  > /proc/sys/kernel/kptr_restrict"
./meltdown-checker

on patched system it should end with output

...
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).

On patched system it should show the following:

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)

Do not install 4.4.0-108-generic on Xenial! It breaks boot/reboot/shutdown/suspend functionality!

Install 4.4.0-109-generic (see USN-3522-3 for details)!

As Robie Basak already wrote, there is a page about Spectre and Meltdown vulnerabilities status in Ubuntu.

Also there are:

N0rbert
  • 99,918
  • 3
    Updates for Ubuntu are scheduled for Januari 9. They may land earlier but I wouldn't count on it. https://insights.ubuntu.com/2018/01/04/ubuntu-updates-for-the-meltdown-spectre-vulnerabilities/ – Raniz Jan 05 '18 at 06:48
  • 4
    The "dmesg | grep isolation" type answers are preferable to this, IMO. Some distributions (at least Debian stretch, maybe others) ported PTI to their older kernel, but not the cpu_insecure flag in /proc/cpuinfo. On those systems, looking in the dmesg log is the only way to check, AFAICT. – Jason C Jan 06 '18 at 18:03
  • 3
    I think the dmesg | grep isolation && echo "patched :)" || echo "unpatched :(" command as listed is unnecessarily dangerous: it doesn't show what line was actually matched, and would also happily print "patched :)" if a random other instance of "isolation" was matched... – Jaap Eldering Jan 06 '18 at 20:24
  • 2
    I would recommend against the second suggestion (grepping /proc/cpuinfo for cpu_insecure). If you put that into a script and you have a CPU in the future where the problem is fixed in its microarchitecture, /proc/cpuinfo will no longer say cpu_insecure and your script will believe the kernel is unpatched even though it is patched. I would also recommend against the third suggestion, as it's too likely that there might be the word isolation in the dmesg output at some point without it referring to kernel page table isolation. – blubberdiblub Jan 07 '18 at 04:28
  • Your first two suggestions will only tell you if the kernel is capable of KPTI, not if it's active. The third is subject to false positives, if some other kernel isolation feature is active. – Mark Jan 07 '18 at 05:40
  • 4
    Upon further investigation, all three of these suggestions are broken. Grepping for isolation will match both Kernel/User page tables isolation: enabled and Kernel/User page tables isolation: disabled on command line. – Mark Jan 07 '18 at 07:31
  • I switched this post to community wiki format. So anyone can improve it. – N0rbert Jan 07 '18 at 10:28
  • Only the last one is positive for Ubuntu 16.04.3 with 4.4.0-108-generic. – Seppo Erviälä Jan 10 '18 at 08:02
  • Wouldn't checking for "kaiser" in /proc/cpuinfo flags suffice? Or can we have this flag even if the page table isolation is disabled at boot but compiled in? – Rmano Jan 10 '18 at 08:19
  • Interestingly, grepping dmesg tells that kpti is enabled for me, but there are no bugs listed in my /proc/cpuinfo. My computer has an Intel Core i7 3630qm CPU and runs elementary OS 0.4 (based on Ubuntu 16.04 LTS). – Magnus Teekivi Jan 10 '18 at 11:28
  • Updated post. Do not install 4.4.0-108! – N0rbert Jan 10 '18 at 12:11
  • The first check returns "unpatched" even with 4.4.0-109 on 16.04.3. The other two return "patched". It seems these checks are not reliable enough... – Andres F. Jan 10 '18 at 12:54
  • I am on 16.04.3 LTS 4.4.0-109-generic and I get the first two are "unpatched" and the last one (dmesg) is "patched". Which one(s) should I trust? – Nova Jan 10 '18 at 22:21
  • Note that after installing the patched kernel on Ubuntu systems with AMD CPU, the grep command above shows "Kernel/User page tables isolation: disabled". At the same time, meltdown-checker reports "meltdown safe". It means that kernel supports Page Tables Isolation but it is disabled as AMD CPUs are not vulnerable to that attack. – rpr Jan 10 '18 at 23:43
  • Also cat /proc/cpuinfo | grep bugs will show something like this: bugs : cpu_meltdown spectre_v1 spectre_v2 – Ahmed Mar 08 '18 at 14:16
18

Run the following command :

dmesg | grep 'page tables isolation'

If it displays enabled, then PTI is enabled. If nothing is displayed or you see 'disabled' in the terminal, then PTI is disabled. Ubuntu has not published the patch yet, so it won't display any message.

Aadhil
  • 394
  • ... or later kernel messages have pushed the bootup messages out of the kernel log buffer. If your kernel prints notices for low-severity stuff like weird network packets, it's common for the boot-time messages to not be part of the dmesg output. See /var/log/kern.log* if it goes back far enough to have the boot messages. Ubuntu used to record boot-time dmesg output to /var/log/dmesg, but doesn't seem to do that anymore. – Peter Cordes Jan 10 '18 at 14:23
  • On 14.04, I got dmesg: invalid option -- 'w'. -H is also invalid. Removing the flags worked fine for me, as in this answer – wjandrea Jan 11 '18 at 20:14
  • /var/log/kern.log on 14.04 – eckes Jan 11 '18 at 22:43
13

You can check with cat /proc/cpuinfo, if it reports cpu_insecure under "bugs", then PTI is enabled.

If it's blank (or just does not list cpu_insecure), then most likely you are running a kernel which has not yet been patched (Ubuntu's hasn't), or you have an AMD processor (for which this will forseeably not be enabled, since they're not vulnerable).

Currently all CPUs are treated as vulnerable in the latest 4.15 kernel.

Jonas Czech
  • 4,017
8

You can run the command below to see all available mitigations (not only for PTI but also for other vulnerabilities) :

$ 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
Michal Przybylowicz
  • 3,672
8

I found this great sh script to test Meltdown/spectre vulnerabilities on your system:

https://github.com/speed47/spectre-meltdown-checker

The script check your system to known Meltdown and spectre patchs on your system to tell you if these vulnerabilities are now mitigated by your OS

2

You can check /proc/config.gz for CONFIG_PAGE_TABLE_ISOLATION=y which means that the kernel was compiled with KPTI.

This is on my patched Arch Linux system running 4.14.11-1:

$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz 
CONFIG_PAGE_TABLE_ISOLATION=y
Raniz
  • 314
  • 3
    Unfortunately, the config of the currently running kernel in /proc/ is not enabled by default in Ubuntu kernels. The (much less elegant) workaround is grepping /boot/config-$( uname -r ) instead. – blubberdiblub Jan 07 '18 at 04:35
  • 5
    That only tells you if the kernel was compiled with KPTI, not if KPTI is active (it can be turned off at boot time, and possibly at runtime). – Mark Jan 07 '18 at 05:31
  • If you've explicitly disabled KPTI via kernel command line parameters you shouldn't need to check if it's active or not. – Raniz Jan 16 '18 at 07:53
1

On my AWS Ubuntu 14.04.5 LTS EC2 instance, I ran

grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-$(uname -r)

It should say:

CONFIG_PAGE_TABLE_ISOLATION=y

For update I did:

sudo apt-get update && sudo apt-get install linux-image-generic

I think also this is OK:

sudo apt-get update
sudo apt-get dist-upgrade

To check kernel version:

uname -r

Needs to be 3.13.0-139-generic or newer.

wjandrea
  • 14,236
  • 4
  • 48
  • 98
drKreso
  • 111