4 ms·

It's by design in a literal sense. AMD enforces security boundaries even with speculative execution. So does ARM on all but a couple of chips.

scott_s 9y ago
I'm talking about Meltdown, which is about a race condition with memory access checking and out-of-order execution, not speculative execution. The paper authors do not give a categorical explanation for why they can't exploit the AMD and ARM chips (Section 6.4), and indicate it may be possible to find an exploit in the future.
- BeeOnRope 9y ago
  It's still speculative execution: Meltdown works because you can speculatively load a location based on an earlier load which will ultimately fault. That's basically the definition of speculative execution: the second load never even occurs in the non-speculative instruction flow. It is also due to memory access checking and out-of-order execution, since those aren't orthogonal to "speculative execution" (and in fact are tightly related).
  - scott_s 9y ago
    Now we're arguing the semantics of "speculative execution." When I use the term, I mean speculatively executing code across branch instructions. I use "out-of-order execution" when instructions inside of a basic block are executed in an order different from how they appear in the instruction stream. This is the terminology I learned in computer architecture courses, it's what I've read in the literature, and it's what the Meltdown and Spectre authors use.
    - BeeOnRope 9y ago
      Well long before these attacks that term had a widely accepted definition in CPU architecture that includes much more than only execution on the other side of a predicted branch. I can't speak to your computer architecture course and I'm not sure what literature you've read (but it's easy to get the impression that it only relates to branches since a lot of literature might only be addressing that aspect), but the Meltdown authors are clear at least (quoting from the pdf): In practice, CPUs supporting out-of-order execution support running operations speculatively to the extent that the processor’s out-of-order logic processes instructions before the CPU is certain whether the instruction will be needed and committed. They go on to note that for the remainder of this paper their use of the term will refer to a more restricted definition related specifically to branch speculation, since that's what they care about. That's fine, and it's good they are clear about it - but it doesn't change the recognized meaning of the term (and indeed their narrowing of the term helps confirms the general definition). They aren't as clear in the Spectre paper, and they focus on branch-related speculative execution since that's what they care about for the purposes of their description, but they don't contradict the idea that speculative execution is limited to branch prediction. Not that the Spectre/Meltdown authors are a particularly authoritative reference for CPU architecture terminology: these are, after all, software guys peeking into the hardware world for the purpose of putting together these attacks. Modern "big" cores are, conceptually, executing most of their instructions speculatively, since wide out-of-order execution windows that that there is a large-degree of divergence from pure in-order and any time any earlier instruction can fault, the remaining instructions are speculative (and the CPU mostly doesn't care: the infrastructure such as the ROB are going to be used regardless of whether the current head of the instruction stream is speculatively or not).
BeeOnRope 9y ago
Well we don't really know, because AMD hasn't said in enough detail, but it is entirely possible that they are totally immune to the Meltdown attack. The crux of it comes down to how their TLB, L1 and out-of-order engine interact. Can a load Y whose address depends on an earlier load X whose entry exists in the TLB but only with the S-bit (supervisor access only) end up actually using the true value of X before it is squashed? Clearly Intel allows it to occur, but it's not obvious that this has to be the way. The TLB, which presumably contains the S-bit, is already on the critical load-to-load dependency path (since the physical tag needs to be used to select the way) so it isn't obvious that the S-check can't happen at the same time and essentially squash the result of the load X before it ever shows up on the bypass network for consumption by Y. On the other hand, it might be slightly easier to let the X result show up up on the bypass network and do the S-check in parallel and then only flag the ROB-entry as squashed after the fact[1] - perhaps it saves a MUX in the critical path. This is very much like unlike Spectre, where it is more or less obvious by the way that almost everyone does branch prediction and speculative execution that you can probably pull of the attacks on modern cores (perhaps with the exception of branch predictors that do a full address check to access the BTB). Here AMD has also tried to claim to some invulnerability, but IMO these claims are much weaker since it seems unlikely that the predictors cannot be trained. AMD is probably just relying on the fact the the predictors are harder to train. [1] It's worth noting that everyone is saying that Intel only applies the security check at retirement - but we don't really know this: we only know they apply it "too late" in that the Y load can consume the result, but it could still be applied before retirement, as little as a few cycles later.

scott_s 9y ago

I'm talking about Meltdown, which is about a race condition with memory access checking and out-of-order execution, not speculative execution. The paper authors do not give a categorical explanation for why they can't exploit the AMD and ARM chips (Section 6.4), and indicate it may be possible to find an exploit in the future.

BeeOnRope 9y ago
It's still speculative execution: Meltdown works because you can speculatively load a location based on an earlier load which will ultimately fault. That's basically the definition of speculative execution: the second load never even occurs in the non-speculative instruction flow. It is also due to memory access checking and out-of-order execution, since those aren't orthogonal to "speculative execution" (and in fact are tightly related).
- scott_s 9y ago
  Now we're arguing the semantics of "speculative execution." When I use the term, I mean speculatively executing code across branch instructions. I use "out-of-order execution" when instructions inside of a basic block are executed in an order different from how they appear in the instruction stream. This is the terminology I learned in computer architecture courses, it's what I've read in the literature, and it's what the Meltdown and Spectre authors use.
  - BeeOnRope 9y ago
    Well long before these attacks that term had a widely accepted definition in CPU architecture that includes much more than only execution on the other side of a predicted branch. I can't speak to your computer architecture course and I'm not sure what literature you've read (but it's easy to get the impression that it only relates to branches since a lot of literature might only be addressing that aspect), but the Meltdown authors are clear at least (quoting from the pdf): In practice, CPUs supporting out-of-order execution support running operations speculatively to the extent that the processor’s out-of-order logic processes instructions before the CPU is certain whether the instruction will be needed and committed. They go on to note that for the remainder of this paper their use of the term will refer to a more restricted definition related specifically to branch speculation, since that's what they care about. That's fine, and it's good they are clear about it - but it doesn't change the recognized meaning of the term (and indeed their narrowing of the term helps confirms the general definition). They aren't as clear in the Spectre paper, and they focus on branch-related speculative execution since that's what they care about for the purposes of their description, but they don't contradict the idea that speculative execution is limited to branch prediction. Not that the Spectre/Meltdown authors are a particularly authoritative reference for CPU architecture terminology: these are, after all, software guys peeking into the hardware world for the purpose of putting together these attacks. Modern "big" cores are, conceptually, executing most of their instructions speculatively, since wide out-of-order execution windows that that there is a large-degree of divergence from pure in-order and any time any earlier instruction can fault, the remaining instructions are speculative (and the CPU mostly doesn't care: the infrastructure such as the ROB are going to be used regardless of whether the current head of the instruction stream is speculatively or not).

BeeOnRope 9y ago

Well we don't really know, because AMD hasn't said in enough detail, but it is entirely possible that they are totally immune to the Meltdown attack. The crux of it comes down to how their TLB, L1 and out-of-order engine interact. Can a load Y whose address depends on an earlier load X whose entry exists in the TLB but only with the S-bit (supervisor access only) end up actually using the true value of X before it is squashed? Clearly Intel allows it to occur, but it's not obvious that this has to be the way. The TLB, which presumably contains the S-bit, is already on the critical load-to-load dependency path (since the physical tag needs to be used to select the way) so it isn't obvious that the S-check can't happen at the same time and essentially squash the result of the load X before it ever shows up on the bypass network for consumption by Y. On the other hand, it might be slightly easier to let the X result show up up on the bypass network and do the S-check in parallel and then only flag the ROB-entry as squashed after the fact[1] - perhaps it saves a MUX in the critical path. This is very much like unlike Spectre, where it is more or less obvious by the way that almost everyone does branch prediction and speculative execution that you can probably pull of the attacks on modern cores (perhaps with the exception of branch predictors that do a full address check to access the BTB). Here AMD has also tried to claim to some invulnerability, but IMO these claims are much weaker since it seems unlikely that the predictors cannot be trained. AMD is probably just relying on the fact the the predictors are harder to train. [1] It's worth noting that everyone is saying that Intel only applies the security check at retirement - but we don't really know this: we only know they apply it "too late" in that the Y load can consume the result, but it could still be applied before retirement, as little as a few cycles later.