25

The Meltdown attack FAQ says that KPTI is the fix for linux. How do I check if KPTI is running/enabled?

Shelvacu
  • 2,333
  • 4
  • 16
  • 29

6 Answers6

17

Linux kernel logs the KPTI status on boot so, running the following command would print the status on patched kernels. If it prints nothing then, KPTI is disabled.

dmesg -wH | grep 'Kernel/User page tables isolation'

Linux Kernel 4.15rc6 has enabled KPTI(Kernel page-table isolation) and it has been back ported to Linux Kernel 4.14.11, 4.9.74, 4.4.109, 3.16.52, and 3.2.97.

So, if you are running any of these versions KPTI is in place. Most distros(running any Linux kernel version) will push an update to the Linux kernel within a day or two to fix Meltdown and spectre.

Note: Add the parameter pti=off to the GRUB in order to disable the KPTI. For info: https://askubuntu.com/questions/19486/how-do-i-add-a-kernel-boot-parameter

Aadhil
  • 274
  • 1
  • 8
  • I understand KPTI impacts performance, so I assume there's an option to turn it off. If so, how can I check that? – Shelvacu Jan 04 '18 at 04:21
  • Meltdown is a serious security flaw in intel that allows any hacker(who knows how to exploit) to read your system's memory. You don't mind a hacker to steal your passwords in your memory? – Aadhil Jan 04 '18 at 05:18
  • 2
    @mohammedaadhil, Meltdown is a local exploit. Without the ability to run code on the target machine, a hacker can't do anything with it. It's mainly a threat to shared hosting and other systems where multiple people run code on the same computer. – Mark Jan 04 '18 at 05:28
  • @mohammedaadhil I meant to say I want to check to make absolutely sure that it is enabled. – Shelvacu Jan 04 '18 at 05:58
  • KPTI can be switched on and off at boot time, during kernel compilation, and many distros will backport critical patches such as this to whatever kernel they support. Checking the kernel version will give neither a definite "yes" nor a definite "no". – Mark Jan 04 '18 at 06:20
  • @Mark "local exploit"? This is not a valid argument. Do you mean to say that it can NEVER be spread remotely? – Aadhil Jan 04 '18 at 07:19
  • Agreed that kernel version is not the definitive factor here – Aadhil Jan 04 '18 at 07:20
  • 3
    @mohammedaadhil, I mean it can never be *performed* remotely. If an attacker cannot run code on a computer, they cannot perform the "Meltdown" attack on that computer. If a computer is sufficiently isolated, the performance loss from KPTI outweighs the security gain, and turning it off makes sense. – Mark Jan 04 '18 at 07:36
  • 1
    @shelvacu Add the parameter `pti=off` to the GRUB in order to disable the KPTI. For info: https://askubuntu.com/questions/19486/how-do-i-add-a-kernel-boot-parameter – Aadhil Jan 04 '18 at 07:52
  • 6
    The vulnerability can probably be exploited via javascript https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ – user2804197 Jan 04 '18 at 12:19
  • Why most distros will fix it `within a day or two` and not before public disclosure? – Bilow Jan 04 '18 at 17:41
  • @Bilow because distro mantainers are regular people like we all are, and realised there is an issue after last days news? Or what do you mean exactly? How can they fix it before they know about it? – Alexandr Paliy Jan 05 '18 at 01:29
  • There is a time (few days or few months) before zero-days are disclosed so that the victim of the bug has time to fix it. Why distro maintainers weren't told about before public disclosure? – Bilow Jan 05 '18 at 10:26
10

Things that do indicate the state of KPTI:

  • In standard kernels, the strings Kernel/User page tables isolation: enabled or Kernel/User page tables isolation: force enabled on command line in the dmesg output means that the kernel is performing kernel page table isolation. The latter message additionally means that the kernel thinks page-table isolation is not required for this CPU.

  • In some vendor-patched kernels (mainly RedHat and derivatives): a nonzero value in /sys/kernel/debug/x86/pti_enabled. The absence of this file does not mean anything, however: the standard kernel does not provide it.

  • In kernel 4.14.18 or newer and the corresponding versions of the LTS kernels, the contents of /sys/devices/system/cpu/vulnerabilities/meltdown: a line beginning with Mitigation: indicates that a mitigation (KPTI, microcode, or something else) is in place, a line beginning with Not affected indicates that the CPU is believed to be unaffected by the issue, and a line beginning with Vulnerable indicates that the CPU is believed to be vulnerable, but no or an insufficient mitigation is in place.

Things that don't indicate the state of KPTI:

  • Kernel version. Kernel 4.14.11 and newer, and the corresponding versions of the 4.1, 4,4, and 4.9 LTS kernels are capable of KPTI, but they can be compiled with it disabled, and it can be disabled at boot time. Additionally, versions older than these are not automatically at risk: some distros have backported the KPTI patches to older kernels.

  • bugs : cpu_insecure in /proc/cpuinfo. The presence of this indicates that if the kernel is compiled for page-table isolation, and if page-table isolation hasn't been disabled at boot time or runtime, then page-table isolation will be used. Additionally, it does not indicate that a CPU is vulnerable to the Meltdown attack: the 4.14.11 kernel sets it for all x86 CPUs, while the 4.14.12 kernel sets it for all non-AMD CPUs, even ones like the Pentium MMX or the "Bonnell" Atom CPUs that aren't vulnerable.

  • CONFIG_PAGE_TABLE_ISOLATION=y in the kernel configuration. This only indicates that the kernel is capable of kernel page-table isolation. KPTI can be disabled at boot time from the kernel command line through the nopti or pti=off options. On some systems, it can be disabled at runtime by writing 0 to /sys/kernel/debug/x86/pti_enabled.

Mark
  • 34,390
  • 9
  • 85
  • 134
8

On a supported kernel:

dmesg | grep 'Kernel/User page tables isolation'

will result in either enabled or disabled.

If there is no result, then the kernel does not have support for KPTI.

foxer
  • 79
  • 1
3

Check dmesg output, like dmesg | grep isolation, to determine whether it is turned on for your running machine.

Some further details are mentioned here: https://lwn.net/Articles/741878/

  • There will be a nopti command-line option to disable this mechanism at boot time.
  • There is the kernel option PAGE_TABLE_ISOLATION that enables the KPTI patches, and if CONFIG_IKCONFIG is enabled you can check for the running kernel by zcat /proc/config.gz | grep CONFIG_PAGE_TABLE_ISOLATION=y
  • There is a feature flag X86_BUG_CPU_INSECURE, and if the CPU is known to be unaffected the page-table isolation is turned off.
S. Huber
  • 131
  • 3
3

Check for a line containing Kernel/User page tables isolation in dmesg output. But since the beginning of the kernel ring buffer may no longer be there, another possibility is to search for the same string in /var/log/kern.log (or one of its rotated versions, or some other log file).

Also note that Xen guests may not have such a line. For instance, this is the silent_disable case in arch/x86/mm/kaiser.c of the Debian/stretch kernel (4.9.65-3+deb9u2):

void __init kaiser_check_boottime_disable(void)
{
[...]
        if (boot_cpu_has(X86_FEATURE_XENPV))
                goto silent_disable;
[...]
disable:
        pr_info("disabled\n");

silent_disable:
        kaiser_enabled = 0;
        setup_clear_cpu_cap(X86_FEATURE_KAISER);
}
vinc17
  • 186
  • 5
  • Note that this is distro-specific -- the message may be in some other log file, or early kernel messages may not be logged at all. – Mark Jan 13 '18 at 02:13
2

I am concerned about the performance impact of the meltdown patch as well. We run most of the workload on Amazon Linux on EC2.

I noticed that the most recent kernel update (build 03 Jan 2018) - 4.9.70-25.242 includes all upstream meltdown patches (check rpm -q --changelog kernel).

By default Amazon Linux kernel 4.9.70-25.242 and later enables page table isolation (CONFIG_PAGE_TABLE_ISOLATION=y) so I reckon as long as this flag is y then KPTI is enabled, unfortunately. I haven't done any performance diff comparison though (it should be noticeable).

Terry Wang
  • 121
  • 3