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

[MartinN]

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, but it's expected to be a doozy in the data center / cloud deployments. Due to the amount of interest in this issue, here are benchmarks of a patched kernel showing the performance impact of the page table isolation patches.

http://www.phoronix.com/vr.php?view=25767

At least we know who's definitely having a happy new year.... not Brian Krzanich.

[oiaohm]

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.

TLB Side Channel Attack does not in fact work on AMD cpu and all arm64 chips I have seen. Its the design of MMU defines if there will be a timing difference or not for memory outside you ring level.

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.

TLB Side Channel Attack is showing core problem. Its only possible because you can hit the addresses of memory that is in kernel space ie ring 0 from lower ring levels. Basically its the 2016 fault but at the time failure to understand how lethal it in fact is. Now when you have something DMA into kernel memory making sections of memory flag write able and those sections of memory are accessible from user-space you have one hell of a lethal bug on your hand.

https://en.wikipedia.org/wiki/Kernel_page-table_isolation

Realy PTI is KASLR. So the PTI patches are KASLR fixed and fixing KASLR fixes the problem of userspace programs accessing kernel working memory on intel x86 processes that may or may not be properly read only. AMD MMU design does not have this issue since it automatically forbids lower ring levels accessing high ring level memory without assignment.

So this is the 2016 flaw that the PTI patches fix. How bad that 2016 flaw was missed because working memory turning read/write in kernel space had been overlooked.

According to reports it allows writing to kernel memory due to some bug in the CPU when doing speculative execution.

That is not the only way memory kernel can end up read/write and with the intel flaw be writable from userspace. The PTI change on x86 is closing a defect a defect found in 2016 that people failed to understand how bad it was.

Yes there was a problem in 2016 of that only beats KASLR not considering that in the process of beating KASLR it was touching kernel space memory from userspace and that kind of sweep and mapping could be used to locate where DMA buffers and other items that change between read only to read write.

Basically 2017 it was worked out how bad that 2016 KASLR breaching bug really was. Yes the PTI patches are doing everything that is required to fix that 2016 bug not in fact fixing where the cpu set kernel space memory read/write instead of read only. If userspace can no longer access those blocks of memory the threat is neutralised. AMD MMU userspace code cannot do those attacks.

So the 30 percent performance hit that was talking about in that blackhat Intel cpu are having to take now and optimisations done to attempt claw back that performance loss.

[bsp2020]

At least we know who's definitely having a happy new year.... not Brian Krzanich.

That SOB already sold all the shares he can possibly sell. https://www.fool.com/investing/2017/...-of-stock.aspx

[RealNC]

It seems NVidia users can't run the patched kernel. The patch changes a previously non-GPL symbol to a GPL one, and the nvidia module build fails:

FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'cpu_tlbstate'

Good times

[andrebrait]

2018 is out to a great start

[cRaZy-bisCuiT]

Good for AMD :P

[MartinN]

That SOB already sold all the shares he can possibly sell. https://www.fool.com/investing/2017/...-of-stock.aspx

Don't worry, if he knew of this crap, there's all kinds of claw back provisions for avoiding responsibility... I would think Intel's board is smarter than to let anyone, including Krzanich get away with any crap.

[Holograph]

Don't worry, if he knew of this crap, there's all kinds of claw back provisions for avoiding responsibility... I would think Intel's board is smarter than to let anyone, including Krzanich get away with any crap.

Nope. All he has to do is not spill the secret that he knew of this problem beforehand. Remember, innocent until proven guilty.

Have the Equifax execs that sold stock before the recent breach been charged with insider trading? I know DOJ said they'd investigate, but is anyone aware of any charges? (Even if Equifax ex-execs are charged, lots of other people in the past have been let off for lack of proof of something obvious - obviousness isn't legal proof)

That said, I hope he does get held legally responsible. Oh so bad.

[Awesome Donkey]

Looks like Apple already fixed this (the first vendor to, actually) in macOS High Sierra 10.13.2 with more stuff added in 10.13.3 according to Alex Ionescu. If you can, you might want to try benchmarking macOS 10.13.1 to 10.13.2 to 10.13.3 beta and see what the performance hit is on macOS.

https://twitter.com/aionescu/status/948610973987831809

[wizard69]

That is interesting Apple is usually slow with these fixes. It would be interesting to see if they have a work around that resolves the performance hit.

Looks like Apple already fixed this (the first vendor to, actually) in macOS High Sierra 10.13.2 with more stuff added in 10.13.3 according to Alex Ionescu. If you can, you might want to try benchmarking macOS 10.13.1 to 10.13.2 to 10.13.3 beta and see what the performance hit is on macOS.

https://twitter.com/aionescu/status/948610973987831809