4 ms·

I would think that any sane implementation would not transmit privileged data to waiting instructions. Look at their Listing 2: Instructions 5 - 7 will be wai

I would think that any sane implementation would not transmit privileged data to waiting instructions. Look at their Listing 2: Instructions 5 - 7 will be waiting for the privileged data from line 4 (they are not speculatively executed since they have a data dependency on line 4). So why is Intel releasing the privileged data to the waiting instructions? An answer could be that violation checking is delayed until retire, but other implementations are possible. Anyway, so it could be that AMD and ARM are vulnerable, but it's possible that they are not.

olliej 9y ago
There are two different issues. 1. Intel only (so far) is related to prefetching privileged memory 2. More or less everyone: Speculatively executing code that has variable execution time.
bonzini 9y ago
> I would think that any sane implementation would not transmit privileged data to waiting instructions. The point of VIPT caches is exactly to use data before all the checks are completed. It's easy to judge the sanity of things ex post, but maybe it's not that easy if it took 20 years to find the issue.
- contrarian_ 9y ago
  I don't believe for a second that nobody came up with this idea before. I believe that nobody until now had the motivation to spend the time actually trying to confirm that it's a problem by developing a PoC. Most people would have given up on the idea simply because CPU vendors are not expected to make such a fundamental mistake.
  - londons_explore 9y ago
    The mistake is clear from the design - thats why all CPU vendors are vulnerable to variants of the same bugs. Previously side channel attacks like this have been seen by the security community as unreliable things which only work in very specific cases and have to be averaged over millions of runs. This attack shows a side channel which is general purpose, reliable, and fast.
    - contrarian_ 9y ago
      > The mistake is clear from the design There is no fundamental reason why speculative instructions should be allowed to mutate the cache. OTOH the contention-based side channel attack on speculation has been public knowledge for over a decade. [1] [1] Z. Wang and R. B. Lee, "Covert and Side Channels Due to Processor Architecture," 2006 22nd Annual Computer Security Applications Conference (ACSAC'06), Miami Beach, FL, 2006, pp. 473-482. doi: 10.1109/ACSAC.2006.20
      - bonzini 9y ago
        > There is no fundamental reason why speculative instructions should be allowed to mutate the cache. There is: hundreds of instructions can be in flight speculatively at the same time, especially if you take hyperthreading into account. Good luck rolling them all back. The question is not whether the cache should be mutated during speculative execution. It's what kinds of speculative execution are allowed, and in some cases it's not even clear if fences should be placed by the programmer (whack-a-mole style), the compiler (not sure how) or the processor (probably not). It's non-obvious enough that how to solve it is to some extent a research problem.
- wilun 9y ago
  About Meltdown, it was well known since even before that speculative execution has to stop at security boundaries.

olliej 9y ago

There are two different issues. 1. Intel only (so far) is related to prefetching privileged memory 2. More or less everyone: Speculatively executing code that has variable execution time.

bonzini 9y ago

> I would think that any sane implementation would not transmit privileged data to waiting instructions. The point of VIPT caches is exactly to use data before all the checks are completed. It's easy to judge the sanity of things ex post, but maybe it's not that easy if it took 20 years to find the issue.

contrarian_ 9y ago
I don't believe for a second that nobody came up with this idea before. I believe that nobody until now had the motivation to spend the time actually trying to confirm that it's a problem by developing a PoC. Most people would have given up on the idea simply because CPU vendors are not expected to make such a fundamental mistake.
- londons_explore 9y ago
  The mistake is clear from the design - thats why all CPU vendors are vulnerable to variants of the same bugs. Previously side channel attacks like this have been seen by the security community as unreliable things which only work in very specific cases and have to be averaged over millions of runs. This attack shows a side channel which is general purpose, reliable, and fast.
  - contrarian_ 9y ago
    > The mistake is clear from the design There is no fundamental reason why speculative instructions should be allowed to mutate the cache. OTOH the contention-based side channel attack on speculation has been public knowledge for over a decade. [1] [1] Z. Wang and R. B. Lee, "Covert and Side Channels Due to Processor Architecture," 2006 22nd Annual Computer Security Applications Conference (ACSAC'06), Miami Beach, FL, 2006, pp. 473-482. doi: 10.1109/ACSAC.2006.20
    - bonzini 9y ago
      > There is no fundamental reason why speculative instructions should be allowed to mutate the cache. There is: hundreds of instructions can be in flight speculatively at the same time, especially if you take hyperthreading into account. Good luck rolling them all back. The question is not whether the cache should be mutated during speculative execution. It's what kinds of speculative execution are allowed, and in some cases it's not even clear if fences should be placed by the programmer (whack-a-mole style), the compiler (not sure how) or the processor (probably not). It's non-obvious enough that how to solve it is to some extent a research problem.
wilun 9y ago
About Meltdown, it was well known since even before that speculative execution has to stop at security boundaries.