Hector Martin

Aaand suddently VM-exit latencies on Intel CPUs will go through the roof, oh, and if you're still putting different guests on sibling hyperthreads you're going to get pwned and you know it. Good job, Intel. You saved a few AND gates. Was it worth it? https://www.redhat.com/en/blog/understanding-l1-terminal-fault-aka-foreshadow-what-you-need-know …

This speculation saga just keeps getting worse and worse, which goes on to show that there's a huge disconnect between CPU designers and security researchers. This is the CPU equivalent of foo = bar[untrusted]; if (untrusted > bound) return 0; do_stuff(foo);. Who does that?!

"Let's use garbage bits for something, it's fine, we'll throw away the result later". No. No it isn't fine. Why the fuck would that ever be a good idea? If you can't take the fault immediately at least poison the garbage data with zeroes!

it's honestly not obvious that this is a bad idea other than in hindsight; I know I'd make the same mistake

This is like saying buffer overflows are fine as long as you overflow into data you don't care about anyway. It's basic security hygiene. Betting your security on the bug (it's a bug) not being exploitable.

that's not what I mean; it wouldn't even occur to me (before this all was disclosed) that any speculation is security-sensitive. and indeed it didn't occur to me, or to thousands of way more competent researchers that have certainly known how CPUs work since speculation existed