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

[phoronix]

Phoronix: Linux Will End Up Disabling x86 PTI For AMD Processors

While at the moment with the mainline Linux kernel Git tree AMD CPUs enable x86 PTI and are treated as "insecure" CPUs, the AMD patch for not setting X86_BUG_CPU_INSECURE will end up being honored...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI

[ddriver]

Intel is silently weeping. Well, one cannot blame them for trying.

[Holograph]

Intel is silently weeping. Well, one cannot blame them for trying.

Wait and see, because if it does take until 4.16 to fix the problem for AMD (thus restoring performance), that's still a couple extra months where Intel's performance is artificially ahead of AMD's for end users that don't know how to fix things themselves, which still isn't quite acceptable.

[chuckula]

People who think that PTI was only made to fix a specific bug are going to be in a for a rude shock down the line, and there's no reason to think that it won't need to be turned on for AMD's parts in the future because isolating page tables is a good idea even if this specific bug doesn't affect RyZen.

[ddriver]

People who think that PTI was only made to fix a specific bug are going to be in a for a rude shock down the line, and there's no reason to think that it won't need to be turned on for AMD's parts in the future because isolating page tables is a good idea even if this specific bug doesn't affect RyZen.

Intel fanboys can only hope and have wet dreams about it.

PTI was intended to isolate kernel from user space. But thanks to zen's design it does seem like it is a non issue. Zen fixes the issue that was the sole motivation of PTI and renders it obsolete and unnecessary. There is absolutely no good reason to enable PTI on zen chips.

And yes, intel's best play is to drag it as slow as possible, to make it so that PTI is enabled by default for chips like zen that do not need it only to mitigate its own failure. This is nothing new for intel, a company that is not above spending money to hold its competitor back than to actually innovate and compete. Luckily, PTI can be disabled fairly easy, but still, I imagine quite a lot of users will end up not doing it.

[tankenmate]

@chuckala AMD already do isolate the kernel pages (but doesn't unmap them because it doesn't need to, it doesn't have a permissions problem) and it has been confirmed by AMD. User processes do not have access to kernel pages, the exception being the root user who can manipulate the mappings via syscalls or, if you are feeling particularly obtuse or stupid, via /dev/kmem.

[paulpach]

And yes, intel's best play is to drag it as slow as possible, to make it so that PTI is enabled by default for chips like zen that do not need it only to mitigate its own failure. This is nothing new for intel, a company that is not above spending money to hold its competitor back than to actually innovate and compete. Luckily, PTI can be disabled fairly easy, but still, I imagine quite a lot of users will end up not doing it.

This is not up to Intel. Linus can simply merge the patch from AMD and be done with it, he certainly does not need Intel's permission.

I don't believe this is a conspiracy. Intel engineers are probably under a lot of pressure from this issue. They are trying to close the issue as quickly as possible. I can't imagine them having the time or desire to play politics or test if other chips are affected by the bug. This is kernel development, not house of cards.

[Holograph]

This is not up to Intel. Linus can simply merge the patch from AMD and be done with it, he certainly does not need Intel's permission.

I don't believe this is a conspiracy. Intel engineers are probably under a lot of pressure from this issue. They are trying to close the issue as quickly as possible. I can't imagine them having the time or desire to play politics or test if other chips are affected by the bug. This is kernel development, not house of cards.

It was never on Intel to test this issue with AMD chips and literally nobody is saying it was. But it definitely was Intel's responsibility to only touch code that affects Intel products.

[starshipeleven]

I don't believe this is a conspiracy. Intel engineers are probably under a lot of pressure from this issue. They are trying to close the issue as quickly as possible. I can't imagine them having the time or desire to play politics or test if other chips are affected by the bug. This is kernel development, not house of cards.

Intel engineers are only pawns in this game, the ones that pull the strings are managers.

That said, Intel has no control over Torvalds or others. They can't stop patch merging.

[ddriver]

Linus can simply merge the patch from AMD and be done with it, he certainly does not need Intel's permission.

He can, but will he? And if he doesn't, why wouldn't he? Maybe it is not a matter of permission? Maybe it is a matter of not falling out of favor.