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

Trivia: it doesn't affect AMD

1 Like

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

1 Like

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.


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.

1 Like

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


1 Like

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
1 Like

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.

Sorry, who is Luke?

Thanks @philm,

Do you have an ETA on when linux49: v4.9.74-2 will be available? I've just updated via Octopi and I'm still on v4.9.73-1.



1 Like

Forum kindly sponsored by