Kernel Page-Table Isolation (KPTI) - severe ARM + Intel CPU bug, hits partly AMD



20th Dec.

26th Dec.

29th Dec.

2nd Jan. (german)

[SOLVED] x86 cpu_insecure vulnerabily
[Stable Update] 2018-01-05 - Kernels, KPTI, Plasma, Calamares, TLP
[Testing Update] 2018-01-04 - Kernels, XFCE-Settings, Gimp Development Edition
Les failles Meltdown et Spectre sur Manjaro
[Testing Update] 2018-01-03 - Kernels, Plasma, TLP, Calamares, Update-Notifier
[Testing Update] 2018-01-03 - Kernels, Plasma, TLP, Calamares, Update-Notifier
How to know if my Kernel version contains mitigation of "Intel Meltdown vulnerability"
[Stable Update x32] 2018-01-06 - Kernels, keyring, TLP, Desktop settings
[Stable Update] 2018-01-19 - Kernels, KDE Apps & Framework, Browsers, Virtualbox, Systemd, Mesa
[SOLVED]Strange problem! cpu_insecure bug appeared after update!Trying to get rid of it?
[Testing Update x32] 2018-01-04 - Kernels, Desktop settings, TLP
[Testing Update] 2018-01-04 - Kernels, XFCE-Settings, Gimp Development Edition
[Testing Update] 2018-01-06 - Browsers, Nvidia, PHP, Compiz, Repo-Cleanup
[Stable Update] 2018-01-19 - Kernels, KDE Apps & Framework, Browsers, Virtualbox, Systemd, Mesa
[Testing Update] 2018-01-18 - Kernels, Systemd, Pamac, KDE FW, Haskell, Python
[Stable Update x32] 2018-01-17 - KDE, GCC, Flash, Deepin, lots of other stuff too
Spectre & Meltdown Checker: a useful utility for check your cpu's vulnerability
How to avoid installing the Intel Spectre patch?
[Testing Update] 2018-01-15 - Vertex, Systemd, Haskell, Python, Linux v4.15
[Testing Update] 2018-01-14 - Adapta & Grub Live themes, WebDAD, LibCDIO rebuild
[Stable Update x32] 2018-01-13 - Kernels, Intel microcode
What does the Intel microcode update do?
Did the Intel microcode update 20180108 fix Spectre?
[Testing Update] 2018-01-13 - Architect, Snap, Mesa, Wine, KDE Apps
[Stable Update] 2018-01-12 - Kernels, Microcodes, Nvidia, Firefox, Boost, Cleanup
[Stable Update] 2018-01-12 - Kernels, Microcodes, Nvidia, Firefox, Boost, Cleanup
[Testing Update] 2018-01-11 - Kernels, Systemd, Mesa, Intel Microcode
[Testing Update] 2018-01-09 - Linux316, Nvidia, GCC, Octopi, Firefox
[Stable Update x32] 2018-01-09 - Kernels, many (many) upstream packages updated
[Unstable Update] 2018-01-07 - Boost Rebuild, GCC
[Testing Update] 2018-01-08 - GCC, Nvidia, AMD, Python, Haskell, Clean-Up
[Stable Update] 2018-01-07 - Browsers, Nvidia, PHP, Compiz, Adapta

(moved from #off-topic to #general-discussion as this is kernel-related so definitely on-topic for Manjaro)


Trivia: it doesn’t affect AMD


Seems for me (as ordinary person) backported to Kernel 4.14.11:

  • arch/x86/include/asm/pti.h
  • arch/x86/mm/pti.c
  • include/linux/pti.h


I would wait with the party since all cards are on the table!

And how much is the performance loose on Intel CPUs for every specific task…


I’m kinda on the sure side AMD engineers would know their babies…


13 posts were split to a new topic: Kernel Page-Table thread cleaning


We will enable this “feature” for v4.14.11 and see how Intel works. This won’t affect our AMD CPUs, as we already included the fix by AMD into our kernel.


Please look again in the “ComputerBase” article, it got a update today and will get at least one more tomorrow.

loose translation

The stable Linux kernel 4.14.11 released last night (download) contains for the first time the complete PTI implementation (as well as Linux 4.15-rc6). Whether support for PTI is built into the running kernel reveals the execution of the

zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz

command. If the output is


then the running kernel will support PTI, otherwise it will not. Whether PTI support is not only available but actually used is indicated by the command

dmesg | grep isolation

If the output is

Kernel / User page tables isolation: enabled

then PTI is active, otherwise not.

Linux 4.14.11 still lacks the patch from the AMD developer that disables PTI on AMD CPUs by default. In Linux 4.14.11 PTI is therefore unnecessarily active on AMD CPUs. You can either manually deactivate PTI using the kernel parameter

pti = off

or wait a few days for Linux 4.14.12 - this will contain the patch from the AMD developer.

In short-run own benchmarks ComputerBase was on a notebook with Intel Core i7-4600U in spontaneously running simple benchmarks of the Phoronix Test Suite no beyond the measurement inaccuracy performance determined (tested were pts / blake2, pts / build-linux-kernel, pts / openssl , pts / phpbench, pts / pybench and pts / sqlite). In the tweet mentioned in this news benchmark “time du -s -x /” (So the totaling of the size of all files on the main file system) but we could also notice a significant performance dip: Without PTI, the command delivered in 0.64 seconds Result, with PTI only after 0.82 seconds, which corresponds to a performance penalty of 28%. However, this “benchmark” is to be described as a worst-case, because it consists almost only consists of performing in a loop for each file the “stat” -Syscall.

The widely used PostgreSQL database is running at around 7 percent slower with a PTI benchmark. Linus Torvalds described this performance loss in an answer as “in line with expectations” but of course highly dependent on the actual workload. Meanwhile, there are further PTI benchmarks on Phoronix, which indicate dramatic factor 2 and higher slumps in synthetic file system benchmarks on NVMe SSDs, significant differences in the lower two-digit percentage range for PostgreSQL and Redis databases, and no measurable differences in Encoding benchmarks like FFmpeg and x264 as well as kernel compilation.

ComputerBase gaming-savvy readers will be pleased to note that there is no measurable performance degradation in Phoronix’s game benchmarks, so gamers can probably lean back and relax, at least assuming that the results of the Linux benchmarks are transferable to Windows you should go out first. As it currently looks like at best the charging times could be negatively influenced by PTI.

Details of the vulnerability are expected to be released tomorrow, January 4, 2018.

[Stable Update x32] 2018-01-06 - Kernels, keyring, TLP, Desktop settings

Phoronix did some tests and benchmarks on PTI

Initial Benchmarks Of The Performance Impact Resulting From Linux’s x86 Security Changes

Linux Gaming Performance Doesn’t Appear Affected By The x86 PTI Work


I would like to measure this myself on my machines. Is there a suitable benchmark that measures “overall performance” of a system (not graphics performance).


Apparently this was tested with Intel/AMD (Vega 64, which uses it’s own independent scheduler).
But Nvidia uses cpu scheduling for draw calls, and this relies on kernel level access. So it’ll be interesting to see an Intel/Nvidia benchmark with PTI.


It’s quite a serious bug.

@philm, does nvidia module compile nicely against kernel 4.14.11?
I’ve read on Phoronix that it makes problems with the new implementation.

You would have to run a battery of tests. I/O, raw CPU performance, graphics and interaction of these three. Have a look at what Phoronix uses for their (synthetic) benchmarks.

Regarding the AMD patch, the only thing it does is to enable CPU_INSECURE for every processor that is not VENDOR_AMD, because apparently AMD are not affected, the microarchitecture uses a different model than Intel.


As a reference point, I compiled 387.34 and it appears to be working fine with 4.14.11.

Regarding performance, you will always get “lower” performance when security features are enabled. For example, compiling Python without -fstack-protector-strong -fno-plt (IIRC) will speed it up by 1-2%.

It’s up to you and, in the case of Linux distros, the maintainers, whether that trade-off is worth it. For example, Ubuntu went for the performance boost, Arch for the extra security.


I’ve cleaned the thread a little; I think there was a bit of miscommunication which went off in the wrong direction.


linux414 v4.14.11-1 is already patched to enable PTI on Intel hardware. You can enable it also on AMD hardware via pti=on. It is recommended to keep it on for Intel. If you must, you can disable it via nopti or pti=off. On some hardware you may loose up to 30% - 50% performance. Games however shouldn’t be affected. To follow all the news about this you can go to our Twitter account. There is also plans to update linux44 and linux49. An updated linux415 will follow also.


Update from AMD:

Summary table:

Google Project Zero (GPZ) Research Title Details
Variant One Bounds Check Bypass Resolved by software / OS updates to be made available by system vendors and manufacturers. Negligible performance impact expected.
Variant Two Branch Target Injection Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.
Variant Three Rogue Data Cache Load Zero AMD vulnerability due to AMD architecture differences.

So much for Intel’s earlier “suggestion” that the issues were across all CPUs. Hmph.

For more information (and some pretty logos):



We have patched Manjaro within the following kernel releases:

  • linux415: v4.15.r180104.g00a5ae2-1
  • linux414: v4.14.11-1
  • linux49: v4.9.74-2
  • linux44: v4.4.109-2


Has there been any indication of which processors are affected?

I’ve seen things like “any Intel built in the last decade” or similar, but haven’t seen any specifics.

I ask because my CPU falls just outside “the last decade” and if I don’t have to take a 5 - 50% performance hit I’d rather not.


@Orajnam: If you have an Intel CPU within the Pentium generation or later you’re affected. Also some ARM CPUs are affected. AMD however, uses a modern approach and didn’t copy Intel specifications by the letter. Bryan Lunduke explains it in an understandable manner, if you still have some doubts.