Linux Will End Up Disabling x86 PTI For AMD Processors - Update: Now Disabled

[EricBlair]

"Written by Michael Larabel in Software on 26 December 2017. Page 1 of 2. 17 Comments"

;-)

[Gerii]

Apparently so: https://lkml.org/lkml/2017/12/27/2

While AMD processors are not affected by this particular bug, using PTI can still improve the security of any (x86) system by not leaking kernel address information (which would render KASLR useless).

[oiaohm]

Phoronix: Initial Benchmarks Of The Performance Impact Resulting From Linux's x86 Security Changes

Over the past day you've likely heard lots of hysteria about a yet-to-be-fully-disclosed vulnerability that appears to affect at least several generations of Intel CPUs and affects not only Linux but also Windows and macOS. The Intel CPU issue comes down to leaking information about the kernel memory to user-space, but the full scope isn't public yet until the bug's embargo,
http://www.phoronix.com/vr.php?view=25767

This is what I hate about so called bug embargo on everything.

https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Kernel-Address-Space-Layout-Randomization-KASLR-With-Intel-TSX.pdf

The flaw that the patch is addressing that is causing the performance bug was presented at blackhat USA 2016. So when it publicly presented and is no longer a secret there is really no point to embargo.

The fault is over 12 months old. Windows and OS X have not fixed it yet. So we are well past the acceptable 90 days secret time frames as well.

AMD implement there memory management unit differently. Even so being able to run properly independent tablets for kernel space and userspace could be useful for finding if drivers are using the proper transfer functions or not.

[davidbepo]

guess ill have to add nopti to command line as i dont use any hypervisor

[ernstp]

Using the exact same kernel and the command line parameter sounds like a better idea

[lathiat]

Michael: The documentation shows a flag to disable/enable this on boot, 'pti' and 'nopti'

So would be great to benchmark the same kernel build/benchmarks with this flag on and off to eliminate the other sources of noise.


Thanks for this report, nice to see some more reliable reporting. Anyone would know that du is a pathological worst case when it comes to syscalls.

[Spazturtle]

guess ill have to add nopti to command line as i dont use any hypervisor

You don't need to use a hypervisor to be affected, it's just that they are the most vulnerable. If you disable this security method then somebody can take complete control of your machine simply by having you visit a website that has a malicious script.

[Gerii]

This is what I hate about so called bug embargo on everything.

https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Kernel-Address-Space-Layout-Randomization-KASLR-With-Intel-TSX.pdf

The flaw that the patch is addressing that is causing the performance bug was presented at blackhat USA 2016. So when it publicly presented and is no longer a secret there is really no point to embargo.

The fault is over 12 months old. Windows and OS X have not fixed it yet. So we are well past the acceptable 90 days secret time frames as well.

AMD implement there memory management unit differently. Even so being able to run properly independent tablets for kernel space and userspace could be useful for finding if drivers are using the proper transfer functions or not.

You're mixing things up - although most coverage hasn't been clear on this either. PTI was initially developed to fix the side-channels which leak kernel address information (as discussed in the Blackhat talk) and thus make KASLR useless. These side-channels are possible on any CPU.
KASLR in general is designed to make it harder for an attacker to exploit bugs in the kernel. The Blackhat talk you linked to only shortly discusses PTI without any optimizations as far as I can tell and talks about a performance hit of ~30%. I don't think Linus would have taken this massive performance hit just to save KASLR. A patch set with multiple optimizations has only been made public in October of 2017.
The bug we are talking about now however only affects Intel CPUs but seems to be much worse. According to reports it allows writing to kernel memory due to some bug in the CPU when doing speculative execution. There is no information on when it has been found, but I suppose it has been much later than Blackhat USA 2016.

[L_A_G]

Being a hardware guy I'm very interested in finding out what the actual underlying problem here is. Reading into this some more it sounds an awful lot like Intel got a bit too greedy trying to get the biggest performance benefit possible out of their branch prediction logic and simply screwed up the same way they did with the FDIV bug. Wouldn't surprise me if similarly to the FDIV bug, they knew about it but kept silent thinking nobody would ever notice it.

Does it affect gaming performance?

I seriously doubt it will considering the main issue here is that context switches aren't being done properly (the slowdown is from mitigating against this) and games don't need to do them. Maybe if you're running a bunch of other software in the background or if you're running one of those OnLive type play-games-in-a-VM services, but the average desktop user probably won't notice anything (unless Microsoft or Apple screw up their fix).

Still, seeing how this mostly affects datacenter use cases it does seem like Christmas came a week late for AMD and their Epyc line of server CPUs (which apparently has been selling beyond AMD's own expectations). I doubt Intel will be able to roll out fixed revisions of all their server CPUs any time soon meaning that they'll have to live with a performance handicap in datacenter use cases well into the spring along with a lasting loss of confidence in their products.

[sarmad]

Ouch!