43 ms·

Because it leads to timing attacks as an immediate next issue.

• panick21_ 3y ago
  That's not inherent.
  • sulam 3y ago
    So we’re going to speculatively execute some code and then not speed anything up? I mean, theoretically yes but practically isn’t that the point?
    • panick21_ 3y ago
      The relevant question is if any information leaks to the other processes. And that can be prevent if you take care in your processor design.
  • user6723 3y ago
    The timing attacks result in data leakage between processes, even if the processes are in different VMs. It's a huge problem for cloud providers, but most customers don't fully understand the issue and cloud providers aren't forthcoming that "mitigations" are partial at best, so it's really just a huge problem for cloud customers.
    • willis936 3y ago
      Yes but how are the timing attacks an inherent vulnerability and not the result of an accounting error? If the bookkeeping is done properly and the correct amount of cleanup time on a speculated branch is done I don't see how adjacent processes would leak data.
      • Sirened 3y ago
        This is an idea many have had before but it doesn't quite work. When you do this, you tend to lose all the performance gained from speculative execution. It's essentially data-independent-timing as applied to loads and stores, so you have to treat all hits as if they were misses to DRAM, which is not particularly appealing from a performance standpoint. This is not to mention the fact that you can use transient execution itself (without any side channels) to amplify a single cache line being present/not present into >100ms of latency difference. Unless your plan is to burn 100ms of compute time to hide such an issue (nobody is going to buy your core in that case), you can't solve this problem like this.
        • panick21_ 3y ago
          Some timing difference are inherent but if they are exploitable is the real question. There are paper and tools produced that can give you a high confidence that you are not leaking.
          • Sirened 3y ago
            Much of transient execution research over the years has been invalidated or was complete bogus to begin with. It was extremely easy to get a paper into a conference for a while (and frankly still is) just by throwing in the right words because most people don't really understand the issue well enough to tell what techniques are real and practical or just totally non-functional. You have to stop the leak into side channels in the first place, it's simply not practical to try to prevent secrets from escaping out of side channels. This is, unfortunately, the much harder problem with much worse performance implications (and indeed the reason why Spectre v1 is still almost entirely unmitigated).
        • willis936 3y ago
          Why hits to DRAM? Just use cache for speculated branches. The performance gain of the difference between the length of the speculated branch and the length of the bookkeeping is still there. There are workloads with short branches that would have a performance penalty. In those cases it would be helpful to have a flag in the instruction field to stop speculative execution.