Linus Torvalds Trusts Lisa Su's Commitment to AMD CPU Security

FrgMstr

Just Plain Mean
Staff member
Joined
May 18, 1997
Messages
55,532
Linus Torvalds on Github has posted a few urgent fixes for PTI to address Intel's gaping security hole that we covered earlier today. Of note in his post is that he is confident in excluding AMD processors from the update as the company has been confident that they are not affected by the bug. Here is what Lisa Su said (auto-start video warning).


Exclude AMD from the PTI enforcement. Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead - x86/cpu, x86/pti: Do not enable PTI on AMD processors

UPDATE: Tom Lendacky has made a BIG call!

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.
 
Last edited:
Maybe Krzanich sold his stock so he could buy out AMD ;) ?
 
  • Like
Reactions: c3k
like this
I just want a T-Shirt with the following:

"/* 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);"

Priceless statement! :p
You sure on that code? LOL!
 
I just want a T-Shirt with the following:

"/* 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);"

Priceless statement! :p
There you go. In BLACK and WHITE. Priced to sell - $13.42. 100% of the profit goes to the Leukemia & Lymphoma Society.

AMD Tshirt.jpg
 
The code is over my head so I don't get the joke but the "The moment you realized Bulldozer didn't suck" is awesome! Finally, vindication for us AMD fanboys! Haha!

I'm in for a shirt.
 
Love it. Some additional info if it hasn't been posted already here:

From Linus Torvalds <>
Date Wed, 3 Jan 2018 15:51:35 -0800
Subject Re: Avoid speculative indirect calls in kernel
share 0
share 129
On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen 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 ****
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
 
The code is over my head so I don't get the joke but the "The moment you realized Bulldozer didn't suck" is awesome! Finally, vindication for us AMD fanboys! Haha!

I'm in for a shirt.

It's a pretty basic if not / then statement run on boot --- think of it more like basic 10) All x86 chips are bad; 20) hold off on the security patch that really slows the chip down; 30) If the processor is NOT an AMD chip THEN run chip slowing security patch code.
 
Intels response to this seems to be like they were hoping that it would not be detected.
 
Love it. Some additional info if it hasn't been posted already here:

From Linus Torvalds <>
Date Wed, 3 Jan 2018 15:51:35 -0800
Subject Re: Avoid speculative indirect calls in kernel
share 0
share 129
On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen 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 ****
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

And The Linus (to be differentiated from Linus the Lesser), of course, can always be relied upon to just lay it out there straight :)
 
The code is over my head so I don't get the joke but the "The moment you realized Bulldozer didn't suck" is awesome! Finally, vindication for us AMD fanboys! Haha!

I'm in for a shirt.

It's a patch:
Code:
"/* 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);"

First line is a comment.
Second line with - at front means that line is removed. So the original statement that ALL x86 CPU are insecure is not valid anymore.
Third and fourth line with + are new lines, replacements for second line, which say "if the CPU vendor is not AMD, then CPU has a security bug".
 
It's a patch:
Code:
"/* 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);"

First line is a comment.
Second line with - at front means that line is removed. So the original statement that ALL x86 CPU are insecure is not valid anymore.
Third and fourth line with + are new lines, replacements for second line, which say "if the CPU vendor is not AMD, then CPU has a security bug".

its clearer than trying to make out pages of line code from turbo pascal days.
 
The bug was Christmas for AMD and this is Linus's handwritten christmas card to AMD.

This will be huge for AMD's server business. Good for AMD!
 
It is a sad day really but it proves that big corporations are putting profit before anything else. Let's hope that never happens with AMD ....
 
It is a sad day really but it proves that big corporations are putting profit before anything else. Let's hope that never happens with AMD ....

Intel had many high level execs leave last year citing the company's toxic environment and anti progressive policies, I think Intel has a rotten core and some are getting paid to much for doing a piss poor job.
 
Intel CEO sold millions in stock after company was informed of vulnerability, before disclosure.

https://www.marketwatch.com/story/i...of-vulnerability-before-disclosure-2018-01-03
If this is the case he can face some serious charges for insider trading......that being said.

Looks like with AMD stepping up its game with its latest processors and Intel's horrible security policy for its chips. Its time to look at switching platforms. Here's to hoping the next round of CPU designs from AMD are even better than their latest. I for one will make the switch. I love my Intel 6/12 core machine but with AMD making some advances they have become relevant again. Here's to the rise of the thunderbird 2.0 cores of old taking back the crown!!
 
It's a good day to own a Ryzen.

To all those that do: May the bird of paradise fly up your nose.

I bought blue mere weeks before Ryzen launched.

Know what I got? A hot plate. Now I need to delid the damned thing and lap it.
 
Last edited:
If this is the case he can face some serious charges for insider trading......that being said.

Looks like with AMD stepping up its game with its latest processors and Intel's horrible security policy for its chips. Its time to look at switching platforms. Here's to hoping the next round of CPU designs from AMD are even better than their latest. I for one will make the switch. I love my Intel 6/12 core machine but with AMD making some advances they have become relevant again. Here's to the rise of the thunderbird 2.0 cores of old taking back the crown!!


while i'm happy to see it, i'm afraid this is going to add an extra 100 dollars to ryzen refresh just because they can. hopefully it doesn't though.
 
This is probably the greatest new year in awhile. I finally have a perfectly sound and logical reason to finally replace my 2600k.

Lol I am just realizing the irony of the situation. Intel sold me a sandy bridge, and now its about to get washed away... Seems Intel has been selling a lot of bridges lately...

"If you thought Sandy Bridge was fast, well then we have another bridge to sell you..."

I am so excited I am being redundantly redundant.
 
"The moment you realized Bulldozer didn't suck" is awesome! Finally, vindication for us AMD fanboys! Haha!

I'm in for a shirt.

Same here.

Maybe they will name the new chips something like:
Intel Core i7-8700 Coffee Lake 6-Core 3.2 GHz (4.6 GHz Turbo) LGA 1151 (-30% Series)

Maybe they'll just give up and work out an agreement to resell AMD chips with an Intel heatspreader on top, like they already do with some of their iGPUs.
 
I'm so very torn right now.... Intel has been a Linux booster and so very good to Linux for years.... yet our little buddy AMD and their non-holey prediction setup is shining.

Ohhh do I cry or cheer. lmao
 
I think to be a bit more clear, it hasn't been verified yet if AMD is actually affected by meltdown. So far it seems only Intel is affected by that. However, Intel/AMD/ARM are affected by spectre. You can read about both here including who found them and the whitepapers.
 
I think to be a bit more clear, it hasn't been verified yet if AMD is actually affected by meltdown. So far it seems only Intel is affected by that. However, Intel/AMD/ARM are affected by spectre. You can read about both here including who found them and the whitepapers.

Yes, damn near every processor on the planet seems to be affected by Spectre. To what degree seems to be the question.
 
It's a patch:
Code:
"/* 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);"

First line is a comment.
Second line with - at front means that line is removed. So the original statement that ALL x86 CPU are insecure is not valid anymore.
Third and fourth line with + are new lines, replacements for second line, which say "if the CPU vendor is not AMD, then CPU has a security bug".

It's a pretty basic if not / then statement run on boot --- think of it more like basic 10) All x86 chips are bad; 20) hold off on the security patch that really slows the chip down; 30) If the processor is NOT an AMD chip THEN run chip slowing security patch code.

Ah, got it. Thanks guys.
 
from my readings, malicious code has to be running on said machine. Now, while these new bugs are bad, if you have malicious code running on your machine, thats your first problem.
 
Back
Top