14 ms·

I'm going to be honest, I need an ELI5 here. I know what the meltdown/spectre issues are, and kinda understand what retpoline is.

Johnny555 9y ago
Here's an explanation of retpoline: https://support.google.com/faqs/answer/7625886 https://support.google.com/faqs/answer/7625886 “Retpoline” sequences are a software construct which allow indirect branches to be isolated from speculative execution. This may be applied to protect sensitive binaries (such as operating system or hypervisor implementations) from branch target injection attacks against their indirect branches. The name “retpoline” is a portmanteau of “return” and “trampoline.” It is a trampoline construct constructed using return operations which also figuratively ensures that any associated speculative execution will “bounce” endlessly.
- dingo_bat 9y ago
  Maybe I wasn't clear. Your explanation and the linked article is very informative, but I wanted to understand what's the "garbage" Linus is talking about. As I said, I do understand retpolines from a high level.
  - jpgvm 9y ago
    The garbage part is still somewhat beyond my understanding but as I see it he isn't so much talking about the decision to not disable insecure branch prediction by default but rather addressing some very weird behaviour the patches add to kernel entry/exit points. Namely writing to MSRs (Model Specific Registers). This seems non-sensical as the branch predictor shouldn't need screwing with at this stage because the kernel already has retpoline protection. So he is musing there is further ulterior motives here.. perhaps another vulnerability (beyond Meltdown/Spectre) they are getting out ahead of with these very peculiar changes. He is still ofcourse mad that they don't seem like they want to fix Spectre correctly but that seems tangential to how pissed he is that they are trying to get code merged that clearly does something other than just mitigate Spectre. Unfortunately this entire thread is derailed with garbage about how Linus talks, rather than the fact he thinks Intel is doing something really fucking dodgy here and we should all try work out what it is.
aidenn0 9y ago
Linus seems to have two complaints: 1) Recent patch submissions imply that Intel has no good hardware or microcode mitigation for spectre-like attacks. There is a sub-complaint that Intel has a bad (i.e. kills performance) fix, but will not enable it by default because benchmarks matter. 2) This series of patches in particular appears to be doing either something different, or more than what their descriptions imply These patches do various things, presumably to manipulate the opaque internal state of the CPU, but only Intel knows for sure precisely what they do.
- lucb1e 9y ago
  (FYI you're missing your [1] reference.)
  - aidenn0 9y ago
    Thanks, I had a footnote, but decided it would be more confusing than clarifying at the ELI5 level.
- ForHackernews 9y ago
  > Intel has no good hardware or microcode mitigation for spectre-like attacks I was under the impression that for at least one category of attack, there is no hardware mitigation possible because it's a fundamental problem with the x86-64 design. Fixing it would require building a chip that uses some other architecture. Is that not the case?
  - chowells 9y ago
    That's not exactly true. You could build an x86-64 chip without these flaws, but it would require a new internal architecture with a lot more silicon. One obvious approach would be to have two caches per core. Speculative execution would use a different cache than normal execution. If the speculative action is committed to, it swaps which cache is the normal one and which is the speculative one. Then you'd also need to flush the branch predictor on context changes. And a few other issues. Nothing that's impossible to do, but it would require a huge amount of new design and a lot more silicon just to maintain the performance of current chips without mitigation.
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?
ndh2 9y ago
There's a follow up email that has much more details. Not ELI5 though. > But since the peanut gallery is paying lots of attention it's probably worth explaining it a little more for their benefit. http://lkml.iu.edu/hypermail/linux/kernel/1801.2/05282.html http://lkml.iu.edu/hypermail/linux/kernel/1801.2/05282.html

Johnny555 9y ago

Here's an explanation of retpoline: https://support.google.com/faqs/answer/7625886 https://support.google.com/faqs/answer/7625886 “Retpoline” sequences are a software construct which allow indirect branches to be isolated from speculative execution. This may be applied to protect sensitive binaries (such as operating system or hypervisor implementations) from branch target injection attacks against their indirect branches. The name “retpoline” is a portmanteau of “return” and “trampoline.” It is a trampoline construct constructed using return operations which also figuratively ensures that any associated speculative execution will “bounce” endlessly.

dingo_bat 9y ago
Maybe I wasn't clear. Your explanation and the linked article is very informative, but I wanted to understand what's the "garbage" Linus is talking about. As I said, I do understand retpolines from a high level.
- jpgvm 9y ago
  The garbage part is still somewhat beyond my understanding but as I see it he isn't so much talking about the decision to not disable insecure branch prediction by default but rather addressing some very weird behaviour the patches add to kernel entry/exit points. Namely writing to MSRs (Model Specific Registers). This seems non-sensical as the branch predictor shouldn't need screwing with at this stage because the kernel already has retpoline protection. So he is musing there is further ulterior motives here.. perhaps another vulnerability (beyond Meltdown/Spectre) they are getting out ahead of with these very peculiar changes. He is still ofcourse mad that they don't seem like they want to fix Spectre correctly but that seems tangential to how pissed he is that they are trying to get code merged that clearly does something other than just mitigate Spectre. Unfortunately this entire thread is derailed with garbage about how Linus talks, rather than the fact he thinks Intel is doing something really fucking dodgy here and we should all try work out what it is.

aidenn0 9y ago

Linus seems to have two complaints: 1) Recent patch submissions imply that Intel has no good hardware or microcode mitigation for spectre-like attacks. There is a sub-complaint that Intel has a bad (i.e. kills performance) fix, but will not enable it by default because benchmarks matter. 2) This series of patches in particular appears to be doing either something different, or more than what their descriptions imply These patches do various things, presumably to manipulate the opaque internal state of the CPU, but only Intel knows for sure precisely what they do.

lucb1e 9y ago
(FYI you're missing your [1] reference.)
- aidenn0 9y ago
  Thanks, I had a footnote, but decided it would be more confusing than clarifying at the ELI5 level.
ForHackernews 9y ago
> Intel has no good hardware or microcode mitigation for spectre-like attacks I was under the impression that for at least one category of attack, there is no hardware mitigation possible because it's a fundamental problem with the x86-64 design. Fixing it would require building a chip that uses some other architecture. Is that not the case?
- chowells 9y ago
  That's not exactly true. You could build an x86-64 chip without these flaws, but it would require a new internal architecture with a lot more silicon. One obvious approach would be to have two caches per core. Speculative execution would use a different cache than normal execution. If the speculative action is committed to, it swaps which cache is the normal one and which is the speculative one. Then you'd also need to flush the branch predictor on context changes. And a few other issues. Nothing that's impossible to do, but it would require a huge amount of new design and a lot more silicon just to maintain the performance of current chips without mitigation.

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?

ndh2 9y ago

There's a follow up email that has much more details. Not ELI5 though. > But since the peanut gallery is paying lots of attention it's probably worth explaining it a little more for their benefit. http://lkml.iu.edu/hypermail/linux/kernel/1801.2/05282.html http://lkml.iu.edu/hypermail/linux/kernel/1801.2/05282.html