6 ms·

Big simplification: Proper way to fix an hardware bug like this, is that newer cpu gets protected by default, and they answer they are when queried. So you ca

by nolok 9y ago

Big simplification: Proper way to fix an hardware bug like this, is that newer cpu gets protected by default, and they answer they are when queried. So you can ask the CPU "what's your status on bug X" and the cpu answers "i'm good, you don't need to do anything" (newer fixed chips), or "i know about it but was already built, and need microcode update/special behavior to protect myself" (current chips with microcode update), "no answer / I'm not good" (old chips without update). So new stuff is protected, and you add more protection (and slowdowns, and special stuff) for older chips that don't know how to deal with it. What Intel is trying to do here, is to go the other way: the chips, even the new ones, will stay vulnerable by default, and when queried they say "I have a fix but I don't use it, you can enable it by asking !" and the kernel is supposed to enable it. It's terrible for a lot of reasons, like "boot an older os and it's vulnerable since it doesn't know to call this", "additional code to enable this feature has to run for all of eternity for new chips now, instead of having to run for older chips and being phased out over time", etc ... The reason why Intel does that seems obvious: by default the chip does not lose speed since the fix is not enabled, and so instead of "intel chips lose 30% speed over night because of a flaw" it becomes "intel adds a special security mode that protects you even more for critical applications, at the cost of some speed". Purely marketing speech and decision at the cost of proper engineering decisions, and they need and try to get OSes like Linux to play along. That's what he means by "[it] shows intel had no intention of fixing those flaws". Additionally there seems to be a second issue in that the quality and behavior of the patches they submitted are trying to hide this deceptively simple but technically terrible behavior by making it look/sound obtuse and complicated. In other words, intel is using its presence and weight to try and push a shitty solution, but one that is better for them marketing wise. Linus is flabbergasted to be treated like an idiot or a obedient drone that should apply such obvious abusive patches.

lucb1e 9y ago
This doesn't make sense though. If Intel indeed plans to leave chips vulnerable except if you set a flag, then how are these bullshit patches? This will be the only solution Intel is going to deliver right? I get that he doesn't like it, but that doesn't explain why he feels lied to. If Intel says "we're going to not turn the patch on by default", wherein does he suspect the lie?
- nolok 9y ago
  He's complaining about their "fix" being terrible, but isn't fully against using it the end since as you said, that's all there is going to be to have the chips work properly. The reason he refuses those current patches and directly call it a lie/deception is because of what my last two paragraphs related; if you read his message (where the link points to) it's about half way: Intel tries to disguise it by doing it in a convoluted way. Basically they try to avoid making it obvious when looking at the code, because they don't want a "if (intel_chip) enable_fix_because_default_is_broken_on_intel();" and instead pushes something that looks like the kernel needs to do lots of complex stuff [aka, "it's complex, and a fix-on-chip is not enough the kernel needs protection anyway !", and that means a terrible patch with lots of garbage and filler code. Intel's intention is clear in that they specifically pushes this in the same patchset as the "tell the chip to be secure", trying to mush the two things together to make it looks like it's all the same thing, whereas in reality it should be two patchset: one to enable the security mode, and bad for intel marketing wise. And a second one to add those "fixes" to the kernel, that would be refused because terrible and in part unecessary since retpoline already protects it. What Linus is saying is "sure I need the first change, but since you're intent on pushing them together I'm refusing them, because the second one is pure garbage, and you mix them together to hide the first". Eg quotes from said mail to show it's indeed his problem: > So instead they try to push the garbage down to us. And they are doing it entirely wrong, even from a technical standpoint. and > 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. (what he means here is that they try in their patch to make it look like the kernel needs a special protection, while it already has it through retpoline) and > So somebody isn't telling the truth here. Somebody is pushing complete garbage for unclear reasons. Sorry for having to point that out. If this was about flushing the BTB at actual context switches between different users, I'd believe you. But that's not at all what the patches do. (eg "why are you pushing all this crap around to hide what's really happening/need to be executed")
  - lucb1e 9y ago
    That makes sense, thank you!
Eupolemos 9y ago
Thank you.
sundvor 9y ago
Awesome explanation. That is indeed deserving of the word "f*cked". My next CPU will be an AMD then.
- beedogs 9y ago
  That's the upshot of this debacle for me, too. Intel has lost me (again) as a customer.
  - grzm 9y ago
    How did they (temporarily) win you back?
    - beedogs 9y ago
      For a while, they were really the only game in town when AMD was struggling to keep up, performance-wise. Now with Ryzen there's really no reason for me not to switch back. I was an AMD fanboy from the K6-II through a few Athlon revisions.
1911z 9y ago
Thank you for your explanation.
alerighi 9y ago
The problem is that every fix that you could think for Spectre reduces the performance of the CPU. So not enabling this by default it's a good choice, Spectre is very difficult to exploit: so if you do critical things you enable the fix, if you use the computer for gaming, video rendering, and things where you don't care too much about security but you care about performance, you don't enable it.
- eeeficus 9y ago
  Why not the other way around? You have the fix enabled and if you don't know you get protected by default. If you really know better then you can disable the fix (via a special CPU instruction), because you know you're not running anything critical?
  - draugadrotten 9y ago
    > you can disable the fix (via a special CPU instruction) The CPU can not be allowed to disable the fix, because then that could be done by an attacker. Therefore the only more secure way is to move in the secure direction, from insecure to more secure.
    - simias 9y ago
      Nonsense, just make it so that only privileged kernel code can modify this configuration. Tons of CPU configuration parameters already work that way, it's a non-issue. If for some reason you even want to forbid even privileged code from modifying the config then add an other "lock" bit that forbids subsequent reconfiguration till the next reboot.
    - nolok 9y ago
      Uh no, they would obviously make it so only kernel code can run that, like many other such settings. And if an attacker can run code at the kernel level it's a non issue, as they're already on the other side of the airtight hatchway anyway [1]: they're in control of the computer and the memory. [1]: https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=31283 https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=...
gkya 9y ago
Wow. That's outright malicious behaviour from Intel there.
kbenson 9y ago
It's not entirely clear to me, but in some of the followup emails it appears that Linus was mistaking the purpose of some patches (or flags at least) due to unobvious naming, but I'm unsure if that significantly alters his criticism. He says it still applies, but is much more muted in tone about it (and whether that's from the original email possibly not being intended to by public or not, I don't know).
microtherion 9y ago
Thanks for your informative explanation. However… > "boot an older os and it's vulnerable since it doesn't know to call this" Presumably the hardware that fixes this is not even available on the market yet. How likely is it that somebody will go out of their way to install an obsolete OS version on their brand new hardware?
- jessaustin 9y ago
  An obsolete version that runs faster and benchmarks better, which some customers won't realize is less secure? It doesn't seem unlikely...
master_ant 9y ago
> In other words, intel is using its presence and weight to try and push a shitty solution, but one that is better for them marketing wise. Linus is flabbergasted to be treated like an idiot or a obedient drone that should apply such obvious abusive patches. I see where the brashness comes from. Shady dealings on Intel's part.
cryptonector 9y ago
Linus also says that this shows Intel means never to fix Spectre2. Of course, that would only be their current position -- they could change their minds later. That strongly implies that the decision to disable by default is a marketing decision, but take this with salt -- it could also be a bad engineering decision.

by nolok 9y ago

lucb1e 9y ago

This doesn't make sense though. If Intel indeed plans to leave chips vulnerable except if you set a flag, then how are these bullshit patches? This will be the only solution Intel is going to deliver right? I get that he doesn't like it, but that doesn't explain why he feels lied to. If Intel says "we're going to not turn the patch on by default", wherein does he suspect the lie?

nolok 9y ago
He's complaining about their "fix" being terrible, but isn't fully against using it the end since as you said, that's all there is going to be to have the chips work properly. The reason he refuses those current patches and directly call it a lie/deception is because of what my last two paragraphs related; if you read his message (where the link points to) it's about half way: Intel tries to disguise it by doing it in a convoluted way. Basically they try to avoid making it obvious when looking at the code, because they don't want a "if (intel_chip) enable_fix_because_default_is_broken_on_intel();" and instead pushes something that looks like the kernel needs to do lots of complex stuff [aka, "it's complex, and a fix-on-chip is not enough the kernel needs protection anyway !", and that means a terrible patch with lots of garbage and filler code. Intel's intention is clear in that they specifically pushes this in the same patchset as the "tell the chip to be secure", trying to mush the two things together to make it looks like it's all the same thing, whereas in reality it should be two patchset: one to enable the security mode, and bad for intel marketing wise. And a second one to add those "fixes" to the kernel, that would be refused because terrible and in part unecessary since retpoline already protects it. What Linus is saying is "sure I need the first change, but since you're intent on pushing them together I'm refusing them, because the second one is pure garbage, and you mix them together to hide the first". Eg quotes from said mail to show it's indeed his problem: > So instead they try to push the garbage down to us. And they are doing it entirely wrong, even from a technical standpoint. and > 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. (what he means here is that they try in their patch to make it look like the kernel needs a special protection, while it already has it through retpoline) and > So somebody isn't telling the truth here. Somebody is pushing complete garbage for unclear reasons. Sorry for having to point that out. If this was about flushing the BTB at actual context switches between different users, I'd believe you. But that's not at all what the patches do. (eg "why are you pushing all this crap around to hide what's really happening/need to be executed")
- lucb1e 9y ago
  That makes sense, thank you!

Eupolemos 9y ago

Thank you.

sundvor 9y ago

Awesome explanation. That is indeed deserving of the word "f*cked". My next CPU will be an AMD then.

beedogs 9y ago
That's the upshot of this debacle for me, too. Intel has lost me (again) as a customer.
- grzm 9y ago
  How did they (temporarily) win you back?
  - beedogs 9y ago
    For a while, they were really the only game in town when AMD was struggling to keep up, performance-wise. Now with Ryzen there's really no reason for me not to switch back. I was an AMD fanboy from the K6-II through a few Athlon revisions.

1911z 9y ago

Thank you for your explanation.

alerighi 9y ago

The problem is that every fix that you could think for Spectre reduces the performance of the CPU. So not enabling this by default it's a good choice, Spectre is very difficult to exploit: so if you do critical things you enable the fix, if you use the computer for gaming, video rendering, and things where you don't care too much about security but you care about performance, you don't enable it.

eeeficus 9y ago
Why not the other way around? You have the fix enabled and if you don't know you get protected by default. If you really know better then you can disable the fix (via a special CPU instruction), because you know you're not running anything critical?
- draugadrotten 9y ago
  > you can disable the fix (via a special CPU instruction) The CPU can not be allowed to disable the fix, because then that could be done by an attacker. Therefore the only more secure way is to move in the secure direction, from insecure to more secure.
  - simias 9y ago
    Nonsense, just make it so that only privileged kernel code can modify this configuration. Tons of CPU configuration parameters already work that way, it's a non-issue. If for some reason you even want to forbid even privileged code from modifying the config then add an other "lock" bit that forbids subsequent reconfiguration till the next reboot.
  - nolok 9y ago
    Uh no, they would obviously make it so only kernel code can run that, like many other such settings. And if an attacker can run code at the kernel level it's a non issue, as they're already on the other side of the airtight hatchway anyway [1]: they're in control of the computer and the memory. [1]: https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=31283 https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=...

gkya 9y ago

Wow. That's outright malicious behaviour from Intel there.

kbenson 9y ago

It's not entirely clear to me, but in some of the followup emails it appears that Linus was mistaking the purpose of some patches (or flags at least) due to unobvious naming, but I'm unsure if that significantly alters his criticism. He says it still applies, but is much more muted in tone about it (and whether that's from the original email possibly not being intended to by public or not, I don't know).

microtherion 9y ago

Thanks for your informative explanation. However… > "boot an older os and it's vulnerable since it doesn't know to call this" Presumably the hardware that fixes this is not even available on the market yet. How likely is it that somebody will go out of their way to install an obsolete OS version on their brand new hardware?

jessaustin 9y ago
An obsolete version that runs faster and benchmarks better, which some customers won't realize is less secure? It doesn't seem unlikely...

master_ant 9y ago

> In other words, intel is using its presence and weight to try and push a shitty solution, but one that is better for them marketing wise. Linus is flabbergasted to be treated like an idiot or a obedient drone that should apply such obvious abusive patches. I see where the brashness comes from. Shady dealings on Intel's part.

cryptonector 9y ago

Linus also says that this shows Intel means never to fix Spectre2. Of course, that would only be their current position -- they could change their minds later. That strongly implies that the decision to disable by default is a marketing decision, but take this with salt -- it could also be a bad engineering decision.