4 ms·

I'm not a CPU architect, and I'd agree with you that Spectre variant 2 should be fixed by CPU designs, simply because software is helpless against it. Luckily,

I'm not a CPU architect, and I'd agree with you that Spectre variant 2 should be fixed by CPU designs, simply because software is helpless against it. Luckily, fixing it shouldn't be too expensive, it just requires tagging the BTB with the trust zone. But Spectre variant 1 is really a consequence of the CPU working correctly. For a large number of branches, perhaps most, we want loads to proceed during speculative execution. This is because the code accesess the same or closely related data on both sides of the branch, so priming the caches during speculation is very valuable even when the branch is mispredicted. I remember reading a study of different binary search implementations which is probably the clearest example of this: when the data is laid out in a heap layout (with child nodes next to each other in an array) the branchy variant of the code performs better than the branchless variant due to this cache priming effect. What CPU designers could and should probably help with is providing instructions to cheaply mark the (comparatively few!) cases where this speculative execution behaviour leaks secret information.

cesarb 9y ago
> What CPU designers could and should probably help with is providing instructions to cheaply mark the (comparatively few!) cases where this speculative execution behaviour leaks secret information. How can we, as software developers, find these cases in our multi-megabyte code bases, and how can we be sure we haven't missed any?
- fyi1183 9y ago
  You could ask the same question about any class of security bug, so unsurprisingly I'd answer more or less in the same way. For example, if you're paranoid, make your compiler be conservative, in the same way that you might address buffer overflows by using a language/compiler that inserts bounds checks everywhere. If you're less paranoid and/or more worried about performance, invest in static analysis tools or languages with augmented type systems. After all, you only have to worry about Spectre variant 1 when handling attacker-controlled data. Tracking type info like this is already done by existing static analysis tools. Finally, if you're not handling attacker-controlled data at all - which is the case for a lot of performance-sensitive code - you really don't want to (and don't have to) do anything about Spectre variant 1. By the way, this is really the big difference between the two Spectre variants, and why it's a shame that they fall under the same name. Variant 2 affects all code with indirect jumps/calls, even code that doesn't ever touch attacker-controlled data. That's a huge difference between the variants. Anyway, the bottom line is that you shouldn't punish the performance of all code over a class of security bugs that a lot of code isn't affected by. Buffer overflows haven't stopped us and shouldn't stop us from writing performance sensitive but security uncritical code in unsafe languages either.
  - Animats 9y ago
    You could ask the same question about any class of security bug, so unsurprisingly I'd answer more or less in the same way. No. the problem here is that the code isn't wrong. The CPU is wrong. Whether or not the CPU will leak data depends on the make and model of CPU. Most MIPS CPUs and many ARM CPUs don't have this problem. Some AMD x86-type CPUs may not. It has to be fixed on the CPU side. This could introduce Intel to a world auto manufacturers know well - recalls. Intel has been there before, with the floating point bug.
    - fyi1183 9y ago
      You don't actually have an argument though. Why is the CPU wrong? Because you say so? And btw, you're wrong about this not affecting ARM or AMD. It affects everyone with speculative execution (we're only talking about Spectre variant 1 here - if you're confused about that, please go back to my first comment in this thread). Look: When other side channel leaks were found, e.g. people recovering RSA or AES keys from plain cache timing without speculative execution, maybe there were people similarly arguing that it's the CPU's fault. They lost that fight, too. Today, the uncontested consensus is that cache timing leaks are the code's fault, for good reason. Because what are you going to do, stop building caches? Obviously not, they exist for very good reasons. The same is true for speculative execution. What do you expect CPU people to do? Rip that out entirely? Be real. (Please, seriously think about that: what is it that you actually want CPU people to do? Don't just handwave!) This kind of discussion is why Linus Torvalds regularly flames security people.

cesarb 9y ago

> What CPU designers could and should probably help with is providing instructions to cheaply mark the (comparatively few!) cases where this speculative execution behaviour leaks secret information. How can we, as software developers, find these cases in our multi-megabyte code bases, and how can we be sure we haven't missed any?

fyi1183 9y ago
You could ask the same question about any class of security bug, so unsurprisingly I'd answer more or less in the same way. For example, if you're paranoid, make your compiler be conservative, in the same way that you might address buffer overflows by using a language/compiler that inserts bounds checks everywhere. If you're less paranoid and/or more worried about performance, invest in static analysis tools or languages with augmented type systems. After all, you only have to worry about Spectre variant 1 when handling attacker-controlled data. Tracking type info like this is already done by existing static analysis tools. Finally, if you're not handling attacker-controlled data at all - which is the case for a lot of performance-sensitive code - you really don't want to (and don't have to) do anything about Spectre variant 1. By the way, this is really the big difference between the two Spectre variants, and why it's a shame that they fall under the same name. Variant 2 affects all code with indirect jumps/calls, even code that doesn't ever touch attacker-controlled data. That's a huge difference between the variants. Anyway, the bottom line is that you shouldn't punish the performance of all code over a class of security bugs that a lot of code isn't affected by. Buffer overflows haven't stopped us and shouldn't stop us from writing performance sensitive but security uncritical code in unsafe languages either.
- Animats 9y ago
  You could ask the same question about any class of security bug, so unsurprisingly I'd answer more or less in the same way. No. the problem here is that the code isn't wrong. The CPU is wrong. Whether or not the CPU will leak data depends on the make and model of CPU. Most MIPS CPUs and many ARM CPUs don't have this problem. Some AMD x86-type CPUs may not. It has to be fixed on the CPU side. This could introduce Intel to a world auto manufacturers know well - recalls. Intel has been there before, with the floating point bug.
  - fyi1183 9y ago
    You don't actually have an argument though. Why is the CPU wrong? Because you say so? And btw, you're wrong about this not affecting ARM or AMD. It affects everyone with speculative execution (we're only talking about Spectre variant 1 here - if you're confused about that, please go back to my first comment in this thread). Look: When other side channel leaks were found, e.g. people recovering RSA or AES keys from plain cache timing without speculative execution, maybe there were people similarly arguing that it's the CPU's fault. They lost that fight, too. Today, the uncontested consensus is that cache timing leaks are the code's fault, for good reason. Because what are you going to do, stop building caches? Obviously not, they exist for very good reasons. The same is true for speculative execution. What do you expect CPU people to do? Rip that out entirely? Be real. (Please, seriously think about that: what is it that you actually want CPU people to do? Don't just handwave!) This kind of discussion is why Linus Torvalds regularly flames security people.