Naive approach which likely works (but needs verification): never fetch cache lines speculatively, only speculate with already-in-cache data.
Because people sometimes write asm by hand & are likely to get it wrong. But nobody's making a new ISA right now anyway. RV is already spec'd & in use.
-
-
You can add speculation barriers where they are needed.
-
Again, adding them to an existing ISA is pointless because you're not fixing the bug - that you broke the original ISA contract.
-
We've got an actual security issue: it doesn't matter whether we change the ISA contact+modify software to fix. What matters is it gets fixed. And lots of machines won't have this issue.
-
Yes it does matter. You really have no idea what you're talking about.
-
Here "changing the ISA" means "declaring all existing binaries AND TOOLING for the old ISA deprecated and unusable".
-
Could you be specific about what breaks? For most machines in the world only the browser's JIT engine needs a change. For virtualized servers the hypervisor.
-
That's really naive. An interpreter/JIT running hostile code is the most obvious way to exploit Spectre but there's no guarantee it's the only one.
-
I strongly suspect there will be ways to exploit via specially crafted files thought of as "pure data".
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.