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.

up vote 63 down vote accepted
  • 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:

  • 3
    Updates for Ubuntu are scheduled for Januari 9. They may land earlier but I wouldn't count on it. insights.ubuntu.com/2018/01/04/… – Raniz Jan 5 at 6: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 Creighton Jan 6 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 6 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 7 at 4:28
  • 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 7 at 7:31

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.

  • ... 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 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 at 20:14
  • /var/log/kern.log on 14.04 – eckes Jan 11 at 22:43

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.

  • 4.15 is not released yet to the public – AadhilRF Jan 4 at 8:25
  • It is, if you download the latest release candidate from kernel.org and compile it yourself. @Mohammedaadhil – JonasCz Jan 4 at 8:28
  • 1
    A release candidate isn't a release. – Ruslan Jan 4 at 15:36
  • The article you linked has been updated – nixpower Jan 4 at 19:38
  • 2
    Kernel 4.14.11 will set cpu_insecure for any x86 CPU; 4.14.12 and newer will only set it for Intel CPUs (including ones too old or too primitive to be vulnerable. Both will set it even if KPTI is disabled. – Mark Jan 7 at 5:38

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

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
  • 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 7 at 4: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 7 at 5: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 at 7:53

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.