AMD burns Intel with the best Linux Kernel patch ever ensuring that AMD CPU performance is not affected by PTI

[AlTech]

Edit:

It seems a fair amount of you are confused. This does not patch Spectre. This is a patch to ensure that the fix from Intel's vulnerability does not cause performance regressions for AMD.

 

Original:

AMD has submitted a patch to the Linux Kernel in order to ensure that their CPUs do not experience performance regressions due to the recent PTI vulnerability which affects Intel x86-64 CPUs.

 

AMD's method of fixing this was quite humorous and burns Intel a lot.

 

The code AMD added basically says that if Linux is not running on an AMD CPU then it's insecure and the PTI fix which causes performance regression is enabled.

/* Assume for now that ALL x86 CPUs are insecure */
-	setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
+	if (c->x86_vendor != X86_VENDOR_AMD)
+		setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

If it is an AMD CPU which is enabled then PTI fix does not need to be applied.

 

AMD are now happy that the patch for PTI (A community acronym of the fix for the Intel specific CPU vulnerability) is not affecting their CPUs.

PTI stands for Page Table Isolation.

 

This means that it may be possible for AMD to remain competitive single threaded performance wise with Intel depending on how badly Intel is affected.

 

Quote

AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against.  The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.

Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.

 

Of course in the interest of full disclosure, this patch has not been 100% Officially accepted yet however it is highly likely for this patch to be accepted and for AMD to not suffer on Linux as a result of PTI.

 

Apparently it has been accepted and is going into the Linux Kernel .

 

I'm fairly confident that AMD will do well in 2018.

 

Sources:

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

[ItsMitch]

So just 5 lines and AMD hole is fixed, just like that... Hasn't been 5 days yet and it's already turning out to be a shit year.

[tp95112]

I read that it effects AMD, Intel and also ARM

[ignaloidas]

Whats PTI? It's FUCKWIT

[AlTech]

Just now, SC2Mitch said:

So just 5 lines and AMD hole is fixed, just like that... Hasn't been 5 days yet and it's already turning out to be a shit year.

Technically it's an Intel hole. AMD's just making sure that their CPUs are not slower as a result.

[AlTech]

Just now, ignaloidas said:

Whats PTI? It's FUCKWIT

It got changed by Linus Torvalds .

[sazrocks]

5 minutes ago, AluminiumTech said:

Of course in the interest of full disclosure, this patch has not been 100% Officially accepted yet however it is highly likely for this patch to be accepted and for AMD to not suffer on Linux as a result of PTI.

Actually it has been accepted:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00a5ae218d57741088068799b810416ac249a9ce&utm_source=anz

[johnukguy]

1 minute ago, tp95112 said:

I read that it effects AMD, Intel and also ARM

There are three vulnerabilities. Two have been found not to affect AMD CPU's. One has been found that does and that is fixable by a software patch that doesn't impact AMD CPUs. At least according to AMD, so that may be over optimistic at this point. We will have to wait and see.

[AlTech]

1 minute ago, tp95112 said:

I read that it effects AMD, Intel and also ARM

That's something else entirely. That vulnerability is called Spectre. This is PTI.

 

This is the Intel only vulnerability. AMD is patching the kernel to make sure they don't also receive performance regressions.

[sazrocks]

1 minute ago, SC2Mitch said:

So just 5 lines and AMD hole is fixed, just like that... Hasn't been 5 days yet and it's already turning out to be a shit year.

This fix has nothing to do with the AMD hole.

1 minute ago, tp95112 said:

I read that it effects AMD, Intel and also ARM

Not this vulnerability. The one you are thinking of is spectre; this is meltdown.

[AlTech]

Just now, sazrocks said:

Actually it has been accepted:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00a5ae218d57741088068799b810416ac249a9ce&utm_source=anz

Oh Cool. Awesome .

Updating post.

[Stefan Payne]

8 minutes ago, SC2Mitch said:

So just 5 lines and AMD hole is fixed, just like that... Hasn't been 5 days yet and it's already turning out to be a shit year.

For Intel, yeah. 

For everyone else not so much...

But that Bug was there for 20 Years - we are Talking about Pentium PRO area and later.

So if that is the case, then it should have been noticed by somebody and they decided againt fixing it because it would have cost performance.

 

8 minutes ago, tp95112 said:

I read that it effects AMD, Intel and also ARM

AMD already posted that it isn't affected.

We don't know about ARM, they haven't released a statement (yet).

[Drak3]

14 minutes ago, tp95112 said:

I read that it effects AMD, Intel and also ARM

ATM, the only things that are certain are:

There are three variants, two called Spectre and one called Meltdown

 

Intel chips are currently the only known ones affected by Meltdown.

The fix to Meltdown requires changing kernal behavior, and it can have performance hits depending on task and generation.

 

AMD claims to only be affected by one of the Spectre variants.

 

But as of right now, there's a ton of information out there that hasn't been fully verified. Before final conclusions are drawn, the dust needs to settle.

[AresKrieger]

That's all well and fine but Linux is small potatoes market share wise is it handled in windows' patch

[Stefan Payne]

53 minutes ago, AresKrieger said:

That's all well and fine but Linux is small potatoes market share wise is it handled in windows' patch

On the server/workstation front they are not.

Many websites/servers run under Linux...

 

And kinda most mobile phones/tablets.

[leadeater]

1 hour ago, Stefan Payne said:

AMD already posted that it isn't affected.

We don't know about ARM, they haven't released a statement (yet).

ARM is confirmed to be effected by Spectre Variant 1 just like AMD, it's essentially a flaw in modern CPU and operating system design so every x86 processor will be effected. I wonder if IBM Power is too.

[LAwLz]

I am very surprised that this really shitty piece of code got accepted.

People often see AMD as the "good guys" but I don't understand how anyone can read that code and think anything but "wow, AMD sure are douchebags to their competitors". 

What they do right now is making KAISER on by default, except if the OS detects an AMD processor, then it gets turned off. This is bad for 2 reasons.

1) I think it's premature for AMD to disable security features. I think they should be on the safe side for now until a fix for Spectre is out and we know that similar exploits don't appear.

2) They are just covering their own asses while throwing everyone else, including ARM, MIPS and VIA, under the buss. How the detection should work in my opinion, is that it checks for vulnerable processors and then enables KAISER if one is detected. That way you only need one check for all past and future processors. As it is right now, you're gonna need to create this really messy code with lots of OR statements to cover all protected processors. It's just ugly and inefficient code.

[HalGameGuru]

42 minutes ago, LAwLz said:

-snip-

I'm not sure it's AMD's responsibility to develop code to support everyone else's hardware in a third party kernel. If anything, hopefully, this might get a dedicated Linux dev to put out a more robust piece of code that DOES do all that. But, I really don't think it is on AMD to do it for everyone else.

[Nicnac]

aw hell yea

[Jito463]

3 hours ago, LAwLz said:

What they do right now is making KAISER on by default, except if the OS detects an AMD processor, then it gets turned off. This is bad for 2 reasons.

1) I think it's premature for AMD to disable security features. I think they should be on the safe side for now until a fix for Spectre is out and we know that similar exploits don't appear.

2) They are just covering their own asses while throwing everyone else, including ARM, MIPS and VIA, under the buss. How the detection should work in my opinion, is that it checks for vulnerable processors and then enables KAISER if one is detected. That way you only need one check for all past and future processors. As it is right now, you're gonna need to create this really messy code with lots of OR statements to cover all protected processors. It's just ugly and inefficient code.

Regarding 1, this is not about Spectre, it's about Meltdown which only affects Intel.

 

Regarding 2, ARM and MIPS (to the best of my knowledge) don't run x86, and VIA doesn't exist outside of China at the moment.

[LAwLz]

2 hours ago, HalGameGuru said:

I'm not sure it's AMD's responsibility to develop code to support everyone else's hardware in a third party kernel. If anything, hopefully, this might get a dedicated Linux dev to put out a more robust piece of code that DOES do all that. But, I really don't think it is on AMD to do it for everyone else.

If AMD want to add code to the Linux kernel then I think they should do it properly.

Not some half-assed code which only saves their own asses. It just goes to show that peoples' perception that "AMD are the good guys" is completely wrong. They are selfish, corrupt assholes just like most companies. 

 

3 minutes ago, Jito463 said:

Regarding 1, this is not about Spectre, it's about Meltdown which only affects Intel.

 

Regarding 2, ARM and MIPS (to the best of my knowledge) don't run x86, and VIA doesn't exist outside of China at the moment.

VIA exists outside of China. They have been selling CPUs for ages.

Even if they didn't, this is still just badly coded.

[jagdtigger]

11 minutes ago, LAwLz said:

If AMD want to add code to the Linux kernel then I think they should do it properly.

Not some half-assed code which only saves their own asses. It just goes to show that peoples' perception that "AMD are the good guys" is completely wrong. They are selfish, corrupt assholes just like most companies. 

Just face it, every single human being is selfish not just corporations... BTW i think this is just a stop gap measure  until someone makes a better detection algorithm.

[leadeater]

8 hours ago, LAwLz said:

I am very surprised that this really shitty piece of code got accepted.

People often see AMD as the "good guys" but I don't understand how anyone can read that code and think anything but "wow, AMD sure are douchebags to their competitors". 

What they do right now is making KAISER on by default, except if the OS detects an AMD processor, then it gets turned off. This is bad for 2 reasons.

1) I think it's premature for AMD to disable security features. I think they should be on the safe side for now until a fix for Spectre is out and we know that similar exploits don't appear.

2) They are just covering their own asses while throwing everyone else, including ARM, MIPS and VIA, under the buss. How the detection should work in my opinion, is that it checks for vulnerable processors and then enables KAISER if one is detected. That way you only need one check for all past and future processors. As it is right now, you're gonna need to create this really messy code with lots of OR statements to cover all protected processors. It's just ugly and inefficient code.

The security researches found no fault with any of the AMD processors for Meltdown, they tried and the result was no. It's hardly a good idea to apply a kernel patch which effects system wide performance for no confirmed reason that has shown to have a large performance impact.

 

Spectre is a totally different thing altogether and cannot be fixed with a kernel patch.

 

AMD isn't being good or bad they are simply saying that their architecture is not susceptible to this and kernel programmers need to comply with hardware manufacturers as they set out how to interact with their hardware. Both AMD and Intel contribute to the Linux kernel and have done so for years, you should take more notice of what Linus Torvalds had to say about it. He said it was a very bad idea to assume all processors were susceptible and apply a patch to the kernel that assumes so and does not implement a way to be selective about it, we should differ to his advice.

 

Edit:

Also AMD only modified the existing code and put in that conditional statement, before it was on globally by default.

[N0rm]

Quote

On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen <andi@firstfloor.org> wrote:
> This is a fix for Variant 2 in https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
>
> Any speculative indirect calls in the kernel can be tricked to execute any kernel code, which may allow side channel attacks that can leak arbitrary kernel data.

 

Why is this all done without any configuration options?

 

A *competent* CPU engineer would fix this by making sure speculation doesn't happen across protection domains. Maybe even a L1 I$ that is keyed by CPL.

 

I think somebody inside of Intel needs to really take a long hard look at their CPU's, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.

 

.. and that really means that all these mitigation patches should be written with "not all CPU's are crap" in mind.

 

Or is Intel basically saying "we are committed to selling you shit forever and ever, and never fixing anything"?

 

Because if that's the case, maybe we should start looking towards the ARM64 people more.

 

Please talk to management. Because I really see exactly two possibibilities:

 

 - Intel never intends to fix anything

 

OR

 

 - these workarounds should have a way to disable them.

 

Which of the two is it?

 

                   Linus

https://lkml.org/lkml/2018/1/3/797

[Boo Berry]

For those tl;dr users;

 

1) PTI is meant to 'fix' Meltdown (AKA variant 3), which ONLY affects Intel's CPUs (and maybe some ARM CPUs and iDevice CPUs). AMD CPUs are not vulnerable to Meltdown.

2) AMD (along with Intel and ARM) CPUs are vulnerable to one of the two variants of Spectre, AKA variant 1 or Spectre 1. AMD can 'fix' this in software - looks like it can't be fixed for Intel in software since the issue is at a hardware level for Intel. Also I've read that AMD is only vulnerable to Spectre 1 on Linux running a non-default kernel setting. This needs to be researched and verified. AMD CPUs are not vulnerable to variant 2 AKA Spectre 2.

3) PTI initially flagged all x86 CPUs are "insecure" as a precaution, until it was pointed out by AMD that they're not vulnerable to Meltdown.

4) AMD submitted a patch exempting AMD CPUs from PTI after it was known they don't need PTI enabled for AMD users (again, not vulnerable to Meltdown). There's no reason to enable PTI for AMD CPUs at the current time.

5) Said patch has been accepted and merged by upstream, so the next releases of the Linux kernel(s) will exempt AMD CPU users from PTI being enabled.

6) Intel CPUs are vulnerable to variant 1 (Spectre 1), variant 2 (Spectre 2) and variant 3 (Meltdown).

 

I don't see how this is a burn from AMD to Intel? AMD CPUs simply don't need PTI enabled for their CPUs since they're not vulnerable to Meltdown. So why enforce PTI on AMD when it clearly isn't needed?