3 ms·
If you don't feel overwhelmed enough by the misprediction variant of Spectre yet, consider that the cache side effect of speculation is actually desirable in mo
by fyi1183 9y ago
If you don't feel overwhelmed enough by the misprediction variant of Spectre yet, consider that the cache side effect of speculation is actually desirable in most normal cases, because it helps prime caches with data that is likely to be used in the correct branch as well. Just turning it off is not the right way to solve this.
Perhaps this will finally provide enough incentives to model data sensitivity in the type systems of practical programming languages.
- astrange 9y agoIt would be hard to model data-dependent timing of an actual CPU. Integer division is variable time on lots of architectures, but on ARM even multiplication timing is data-dependent! And on desktops you could cause a even mov instruction to stall a few cycles if you can run something before it that uses all the renamed registers - there might be a way to turn this into data dependence and observe it from the perf counters…
- sitkack 9y agoAll shortcuts leak information. Anything with the equivalent of an early return leaks information.
- fyi1183 9y agoYou don't need to model the timing though. What I'm saying with the type system comment is this: the cache side effects of speculation are desirable most of the time but not always. We should find a way to model data sensitivity in the type system so that a compiler can automatically choose to generate a side-effect-free code sequence where the side effects must be avoided (this assumes a future with ISA extensions that allow telling the CPU to prevent such side effects by blocking the speculative execution).