3 ms·
Even of you can detect effects of speculative execution it does not necessarily mean that it is unsound, because the program still functions as expected. It is
by Yujf 4y ago
Even of you can detect effects of speculative execution it does not necessarily mean that it is unsound, because the program still functions as expected.
It is however not secure in many cases, but I also think that newer implementations do better in this regard so it is probably not a fundamental issue.
And about targeting microcode directly, that would be a new ISA which is not desireable and also decoding instructions is not that big of a deal compared to the rest of the core so it is not worth the hassle of switching ISAs.
- nuc1e0n 4y agoIt's not my field of expertise of course, but if the speculative execution microcode knows what has and needs to occur, what's to stop a game of speculative execution vulnerability whack-a-mole occurring? I would think from a security standpoint it would be better to not do perform any operation that isn't necessary. That way there would be no speculative data available that could be snooped upon I would've thought. If compilers had more direct control of the microcode opcodes, speculative execution wouldn't even be so necessary. LLVM is quite good at doing SSA for itself without support for it in the processor as well. We're now emulating a 40 year old architecture even for non legacy software, for what? Heating up silicon? That doesn't seem very energy efficient.
- tambourine_man 4y agoOne positive and unplanned side effect is code density. Besides taking less memory, if you can “decompress” the ISA faster than memory bandwidth would otherwise allow, it’s a net win. There are many other downsides to x86, like variable length instructions, of course, but it’s something to consider.