Linus Torvalds Rips Into Intel

R

rgMekanic

[H]ard|News
Joined
May 13, 2013
Messages
6,943
In a public email chain, the Linux inventor Linus Torvalds, and David Woodhouse, engineer at Amazon in the UK discuss Intel's "fix" for Meltdown/spectre. Never one to pull punches Torvalds exclaims "the patches are COMPLETE AND UTTER GARBAGE."

I can't even pretend to understand the technical parts of Linus' emails, but it's pretty obvious to see, the man isn't happy with what Intel is doing to fix the problem. From what I can gather, Intel is putting things in the patch that are unnecessary or redundant to make it look more substantial, while having the actual fix not be enabled by default. Linus' speculation on why it is not enabled by default is it would make Intel "look bad in benchmarks." Thanks to fightingfi for the story

All of this is pure garbage. Is Intel really planning on making this shit architectural? Has anybody talked to them and told them they are f*cking insane. Please, any Intel engineers here - talk to your managers. If the alternative was a two-decade product recall and giving everyone free CPUs, I'm not sure it was entirely insane.
 
Last edited:
Overheard:

Intel: Mr. Torvalds we've got a firmware patch for you.

Linus: About time.... you #%$#^@$^&

Linus: Applied. Th <click><thud><splat>

Intel: <giggle> Quick pull the patch before anyone else applies it.
 
cjcox said:
Overheard:

Intel: Mr. Torvalds we've got a firmware patch for you.

Linus: About time.... you #%$#^@$^&

Linus: Applied. Th <click><thud><splat>

Intel: <giggle> Quick pull the patch before anyone else applies it.
Click to expand...

Replace the <click><thud><splat> with the broken hyperdrive sound of the Millennium Falcon, and I think it's just about right. :D <wheeoo wheeoo wheeooooooo wheeeeeooooooooo>
 
Essentially they don't want to enable the fix in silicon by default BUT want to expose something that an OS then can make a decision whether to gimp performance (but provides "security")

they want their benchmarks to look good for marketing
 
Last edited:
yeah fuck intel -- hopefully this makes server grade parts cheap as people offload them like crazy -- and then i can just run a custom kernel in my home lab without the patches.
 
from what iv read it's clear than intel is trying to spread the damage to AMD by trying to keep the fix even for the next gen software ( os based) and intel don't get shafted in benchmarks, to the point of making a critical flaw protection optional, all for the sake of benchmarks results.
i think intel is already ran by marketing team, too much monopoly moved engineering talent aside, in alot of things that they do, you feel like a clueless person is in charge or at least have too many seats on the decision making board.
 
Linus sure is a peach. He's not wrong, but damn I couldn't work with the guy. He's always just a full on asshole when he's talking about others. It must be a leader thing. Ballmer, Jobs, Torvalds... Fuck em all.

But, he's not wrong. Intel really needs to get their shit together.
 
I got the feeling that he was complaing more that the code was just really really clunky. That intel is saying they will add a Flag into the code of their new stock that says "hey hey I'm new" please don't enable that patch, adding one more bit of junk into the code forever. I could be wrong though and this could be a lot worse then just ugly ass code Intel wants to enshrine for all X86 time.
 
ChadD said:
I got the feeling that he was complaing more that the code was just really really clunky. That intel is saying they will add a Flag into the code of their new stock that says "hey hey I'm new" please don't enable that patch, adding one more bit of junk into the code forever. I could be wrong though and this could be a lot worse then just ugly ass code Intel wants to enshrine for all X86 time.
Click to expand...

Basically, he's saying that, instead of doing things "the right way" Intel is just tossing out a "hacked together with parts bin scraps" solution to avoid the lawyers and say they "fixed" the problem. Thing is, this appears that this hacked together "solution" is going to persist on newer procs as well until Intel can find a way to make "the right way" worth their while (aka: profitable).

If you jump 3 messages ahead of the linked one in the thread, David provides some nice background on the technical side of things.
 
My understanding of the e-mail chain is that there is a hardware flag (defaulting to "off") which essentially says - "if you leave me off, I will continue to be broken.... fast, but broken. If you go out of your way to turn me on, I'll be fixed..... slow, but fixed (if you go out of your way, that is)" The end result being that the fixes aren't applied unless you go out of your way to do that.

This is opposed to just having a hardware flag on newer, fixed CPUs that just says "I am new and don't have that 'old CPU' problem, continue processing Business As Usual 'cuz I'm all good"


The implication is that Intel would rather the exploit have a default disabled fix, because that will make their benchmarks look good (after all, the fix is available but disabled) rather then just blanket apply the fix to effected processors and redesign newer processors to not have the problem to begin with.
 
mvmiller12 said:
My understanding of the e-mail chain is that there is a hardware flag (defaulting to "off") which essentially says - "if you leave me off, I will continue to be broken.... fast, but broken. If you go out of your way to turn me on, I'll be fixed..... slow, but fixed (if you go out of your way, that is)" The end result being that the fixes aren't applied unless you go out of your way to do that.

This is opposed to just having a hardware flag on newer, fixed CPUs that just says "I am new and don't have that 'old CPU' problem, continue processing Business As Usual 'cuz I'm all good"


The implication is that Intel would rather the exploit have a default disabled fix, because that will make their benchmarks look good (after all, the fix is available but disabled) rather then just blanket apply the fix to effected processors and redesign newer processors to not have the problem to begin with.
Click to expand...

This is what I got as well
 
David's response to Linus.
On Sun, 2018-01-21 at 14:27 -0800, Linus Torvalds wrote:
> On Sun, Jan 21, 2018 at 2:00 PM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> >>
> >> The patches do things like add the garbage MSR writes to the kernel
> >> entry/exit points. That's insane. That says "we're trying to protect
> >> the kernel". We already have retpoline there, with less overhead.
> >
> > You're looking at IBRS usage, not IBPB. They are different things.
>
> Ehh. Odd intel naming detail.
>
> If you look at this series, it very much does that kernel entry/exit
> stuff. It was patch 10/10, iirc. In fact, the patch I was replying to
> was explicitly setting that garbage up.
>
> And I really don't want to see these garbage patches just mindlessly
> sent around.

I think we've covered the technical part of this now, not that you like
it â not that any of us *like* it. But since the peanut gallery is
paying lots of attention it's probably worth explaining it a little
more for their benefit.

This is all about Spectre variant 2, where the CPU can be tricked into
mispredicting the target of an indirect branch. And I'm specifically
looking at what we can do on *current* hardware, where we're limited to
the hacks they can manage to add in the microcode.

The new microcode from Intel and AMD adds three new features.

One new feature (IBPB) is a complete barrier for branch prediction.
After frobbing this, no branch targets learned earlier are going to be
used. It's kind of expensive (order of magnitude ~4000 cycles).

The second (STIBP) protects a hyperthread sibling from following branch
predictions which were learned on another sibling. You *might* want
this when running unrelated processes in userspace, for example. Or
different VM guests running on HT siblings.

The third feature (IBRS) is more complicated. It's designed to be
set when you enter a more privileged execution mode (i.e. the kernel).
It prevents branch targets learned in a less-privileged execution mode,
BEFORE IT WAS MOST RECENTLY SET, from taking effect. But it's not just
a 'set-and-forget' feature, it also has barrier-like semantics and
needs to be set on *each* entry into the kernel (from userspace or a VM
guest). It's *also* expensive. And a vile hack, but for a while it was
the only option we had.

Even with IBRS, the CPU cannot tell the difference between different
userspace processes, and between different VM guests. So in addition to
IBRS to protect the kernel, we need the full IBPB barrier on context
switch and vmexit. And maybe STIBP while they're running.

Then along came Paul with the cunning plan of "oh, indirect branches
can be exploited? Screw it, let's not have any of *those* then", which
is retpoline. And it's a *lot* faster than frobbing IBRS on every entry
into the kernel. It's a massive performance win.

So now we *mostly* don't need IBRS. We build with retpoline, use IBPB
on context switches/vmexit (which is in the first part of this patch
series before IBRS is added), and we're safe. We even refactored the
patch series to put retpoline first.

But wait, why did I say "mostly"? Well, not everyone has a retpoline
compiler yet... but OK, screw them; they need to update.

Then there's Skylake, and that generation of CPU cores. For complicated
reasons they actually end up being vulnerable not just on indirect
branches, but also on a 'ret' in some circumstances (such as 16+ CALLs
in a deep chain).

The IBRS solution, ugly though it is, did address that. Retpoline
doesn't. There are patches being floated to detect and prevent deep
stacks, and deal with some of the other special cases that bite on SKL,
but those are icky too. And in fact IBRS performance isn't anywhere
near as bad on this generation of CPUs as it is on earlier CPUs
*anyway*, which makes it not quite so insane to *contemplate* using it
as Intel proposed.

That's why my initial idea, as implemented in this RFC patchset, was to
stick with IBRS on Skylake, and use retpoline everywhere else. I'll
give you "garbage patches", but they weren't being "just mindlessly
sent around". If we're going to drop IBRS support and accept the
caveats, then let's do it as a conscious decision having seen what it
would look like, not just drop it quietly because poor Davey is too
scared that Linus might shout at him again. :)

I have seen *hand-wavy* analyses of the Skylake thing that mean I'm not
actually lying awake at night fretting about it, but nothing concrete
that really says it's OK.

If you view retpoline as a performance optimisation, which is how it
first arrived, then it's rather unconventional to say "well, it only
opens a *little* bit of a security hole but it does go nice and fast so
let's do it".

But fine, I'm content with ditching the use of IBRS to protect the
kernel, and I'm not even surprised. There's a *reason* we put it last
in the series, as both the most contentious and most dispensable part.
I'd be *happier* with a coherent analysis showing Skylake is still OK,
but hey-ho, screw Skylake.

The early part of the series adds the new feature bits and detects when
it can turn KPTI off on non-Meltdown-vulnerable Intel CPUs, and also
supports the IBPB barrier that we need to make retpoline complete. That
much I think we definitely *do* want. There have been a bunch of us
working on this behind the scenes; one of us will probably post that
bit in the next day or so.

I think we also want to expose IBRS to VM guests, even if we don't use
it ourselves. Because Windows guests (and RHEL guests; yay!) do use it.

If we can be done with the shouty part, I'd actually quite like to have
a sensible discussion about when, if ever, we do IBPB on context switch
(ptraceability and dumpable have both been suggested) and when, if
ever, we set STIPB in userspace.
Click to expand...
 
viper1152012 said:
All I want is a Processor that doesn't place my ass out in the open for any hacker to infiltrate.....

Is that to much to ask.
Click to expand...

I get what you want, but not going to happen imo, someone always finds a way to hack something, if not by this flaw they will find another one.
 
I really hope class action suit comes against Intel. There probably is already one but seriously they know about this bug and how long will it be before they put something out where does not let us lose performance and the security hole is fixed. This issue is being discussed very seriously at a Medical Corporation I work for and they are nervous that it will put a huge impact on our systems. By the way we are not talking about just single Hospital. This company is one of the largest in the USA and owns a lot of hospitals so it is going to effect a lot of equipment. I can promise you nurses and physicians are going to be all over are tale ends if this slows down our servers.
 
...if the original silicone had a way to obviate the meltdown, then there would have not been a situation that spelled disaster. Intel would have "slowed down the CPU to save battery life", unknown to their customers.

This is a sublime patch because when you are in the business of designing CPU's with more transistors that existed in the world when the first CPU was designed you tend to find where a switch already engineered can be found to mitigate the disaster.

Its something that will be better than a real fix that might take new silicone.

As far as Mr. Torvalds, I bet he knows that the real issue is finding a way to keep processing speed up, while not being able to find a 'finger print' on recently processed data. Its possible that since he is a software guy, he cant understand that baked silicone has to anticipate issues b4 they are known.

It just may be that he is looking at it as a new 'point release', when in reality it could be much deeper....hopefully not.......

Software guys: Its hardware

Hardware guys: its software

...and the customer waits for them to figure it all out.........
 
Denpepe said:
I get what you want, but not going to happen imo, someone always finds a way to hack something, if not by this flaw they will find another one.
Click to expand...

I think we're going to have to settle for feeling fast, while feeling like the ass is safe. I mean, I already feel smart most of the time despite having no idea what Linus is talking about.. so feeling fast and safe should be easy enough.
 
atarione said:
So... intel has basically f*cked us all for the foreseeable future is that about right?
Click to expand...

It depends:

Bartender: you want another B4 we close?

Customer: sure, make it just the way as B4

Bartender: I will give you half for free or you can get a full glass for half price.

Customer: Give me the free one.

Bartender: for this transaction, I will need yourSS# and ID.

Customer: I thought you said it was free?

Bartender: Well, we need some info on you, in order to give you a free one.

Customer: free means that I get it and you only give me the half full drink.

Bartender: Well if you want free, there are things that we get as an exchange.

Customer: You mean that I cant get half a 'free' drink without you knowing where I live and true identity?

Bartender:We sell the info about you, its how we are able to give you free stuff.

Customer: Now that I think about it, make mine a full glass.

Bartender: Ok. That will be half price, you need to swipe your card.

Customer: Cash!

Bartender: Who was that guy?????


Just to say that there are many billions of ip addresses. If you go to a site that is questionable, you might become part of their database. In general, normal webbi'n habits are too low key to bring attention to us. Its the major players that will have focus from the guys that may engineer a hack that takes advantage of spectre and meltdown.

Worlds population = over 7 billion

Hackeable Ip addreses (ip v6) 340,282,366,920,938,463,463,374,607,431,768,211,456

Somewhere in the 431,768,211,456, we live. Just the 431,768,211,456 of the whole.

The risk of a real problem is had by the major servers that serve us. They have to be more concerned.

We are too far along to have another "War of the worlds".

But, no telling what someone would do if no protection was offered on a 'not patched' computer'.

Update and deal with a lil performance hit. It will get better and normal security updates will be be back in fashion.
 
rgMekanic said:
As I said I can't even pretend to understand half the technical stuff from those threads, but I'll be damned if it doesn't look like Spectre/Meltdown isn't even worse than we originally thought.
Click to expand...
And the fixes just make it worse.....
Maybe they need to just bite the bullet and redo the cpu....
 
Government Prosecutor: State your name for the record.

Linus Torvalds: I am Linus Torvalds.

Prosecutor: Do you know the defendant?

Torvalds: Yes, I know the Intel Corporation. It is most kind and generous. It is a cup overflowing with the cream of human goodness. I have never known it to do anything immoral.
Unless maybe the Preschooler's Prostitute Ring.
And he has never done anything illegal.​
Unless you count all the times it sold dope disguised as a nun.
It has always been a good, law-abiding corporate citizen ...​
Give me a break!
... of the United States ...​
Shut up! Shut up!
A community-conscious entity.​
Intel?! It's just a low-down, double-dealing, backstabbing, larcenous, perverted worm! Hanging is too good for it! Burning is too good for it! It should be torn into little pieces and buried alive! I will kill it! Kill!!​
 
From what I understand, Intel wants to put a switch in their CPUs that turns on the Meltdown fix but by default it's off. Thus the CPU by default runs fast until the OS flips the switch to make it run slower. Which kinda puts the blame on the OS instead of the CPU. And of course having a security feature off be default isn't exactly a good idea.
 
Also once the "fix" is out people will reverse engineer it and create apps and scripts that will still work with the backdoor.
 
trudude said:
Also once the "fix" is out people will reverse engineer it and create apps and scripts that will still work with the backdoor.
Click to expand...
I have thought this exactly. The fix is software, software can be hacked, hardware not so much. Maybe somebody will provide a "patch" you download to increase your performance or something. people are very gulable.


I will not buy Intel if I can. AMD will be my choice, since they are not taking performance shortcuts.
 
DukenukemX said:
From what I understand, Intel wants to put a switch in their CPUs that turns on the Meltdown fix but by default it's off. Thus the CPU by default runs fast until the OS flips the switch to make it run slower. Which kinda puts the blame on the OS instead of the CPU. And of course having a security feature off be default isn't exactly a good idea.
Click to expand...

You mean the Spectre fix (indirect branch speculation). Unless I'm misreading, Torvalds says they seem to be doing the right thing with Meltdown patches (at the moment), but they seem to be making Spectre fixes optional because of the performance impact:

That's part of the big problem here. The speculation control cpuid
stuff shows that Intel actually seems to plan on doing the right thing
for meltdown (the main question being _when_). Which is not a huge
surprise, since it should be easy to fix, and it's a really honking
big hole to drive through. Not doing the right thing for meltdown
would be completely unacceptable.

So the IBRS garbage implies that Intel is _not_ planning on doing the
right thing for the indirect branch speculation.

Honestly, that's completely unacceptable too.
Click to expand...

More importantly, this bit implies that he thinks Intel may not be disclosing additional problems:
The patches do things like add the garbage MSR writes to the kernel
entry/exit points. That's insane. That says "we're trying to protect
the kernel". We already have retpoline there, with less overhead.

So somebody isn't telling the truth here. Somebody is pushing complete
garbage for unclear reasons. Sorry for having to point that out.
Click to expand...
 
why doesn't Intel just release and force the patch and then also unlock turbo on 'all' cores as a goodwill measure, a kind of 'robbing Peter to pay Paul' situation, they 'usually' have loads of thermal scope to be able to do it. My E5-2695 V3 has turbo enabled on all 14 cores via UEFI hack, after running Prime95 for an hour it never goes above 62c.. seems like an easy way to save face a little to me..
 
What people do not get is what the complaints are about.

1. The work is done by lawyers
2. The patch is garbage.

http://fudzilla.com/news/processors/45428-intel-s-patch-is-garbage

"I'm sure there is some lawyer there who says 'we'll have to go through the motions to protect against a lawsuit'. But legal reasons do not make for good technology or good patches that I should apply."
Click to expand...

The patch as it is now is a guide for engineers how to circumvent lawsuits by not crippling performance on Intel products.
Torvalds is not happy with this approach be basically says it is not much of a patch for meltdown.

If Intel would apply a proper patch for meltdown it would seriously cripple performance but then it is completely secure

In the end this would seriously cripple performance. By implying this Torvalds more or less means that you want a secure system you would have to change to AMD hardware because if there is a proper patch for Intel system the performance hit will be grounds for lawsuits ....
 
Last edited:
You must log in or register to reply here.
Back
Top