Anyone want to place bets on whether the first actual fix for Spectre will be via reverse engineered and patched microcode?https://twitter.com/thorstenholz/status/1031839729145311232 …
You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
I think there's a really good chance someone who studied the way the microcode works deeply enough would find a way to disable speculation, make all instructions speculation barriers, kill all branch prediction, or do something else that would completely defang Spectre.
It’s the interface between C and the CPU. Manages languages that have array bounds like C# would be able to express the dependencies required without hand sprinkled speculation barriers. So it is partly C. Ya ideally CPU can not evict based on speculation. Transactional caches.
No. The array bounds are not the range of what's safe to leak. ANY array element except the one the code semantically is supposed to read is not safe to leak.
Consider an emulator written in whatever language with fancy array bounds you like, emulating a machine running untrusted code in multiple privilege domains. Data is all just one big array, bounds do nothing.
I like the idea of a randomised ISA so that payloads need to first crack a high entropy dynamically randomised ISA. Google “crypto binary translation”
This has no relevance to the topic at hand because the attack code doesn't have any relation to the host ISA and no need to know anything about the host running the emulator.
We can also solve L1TF with shadow paging. This was the original rationale for the work on the rv8 JIT engine. Use RISC-V as the IR for dynamic runtime translation/obfuscation with multiple entropy vectors. RISC via CISC to a microop backend. It is however a bit of a pipe dream.
Do you mean Foreshadow? AIUI it's solvable just by not putting data in the unused private bits of not-present PTEs.
But given how awful Intel's been I'd be tempted just to not use PTEs at all, TLBs only, faulting on every miss.
A managed language that has real arrays has more information to inform CPU about speculation safety.
You're mistakenly classifying things as safe which are not safe. No speculative memory access is safe even if it's within array bounds.
It’s more nuanced than saying it’s not C. A C compiler can never figure out where to put mem[__builtin_speculation_safe_value (untrusted)]; unless it puts it on all loads. C arrays are just pointers.
s/Manages/Managed/ Languages
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.