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 …
-
Show this thread
-
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?!
1 reply 3 retweets 25 likesShow this thread -
"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!
2 replies 4 retweets 20 likesShow this thread -
Replying to @marcan42
it's honestly not obvious that this is a bad idea other than in hindsight; I know I'd make the same mistake
3 replies 0 retweets 0 likes -
Replying to @whitequark @marcan42
I mean, actual professional cryptographers fucked up AES implementations with secret-dependent lookups, and you're talking about CPU architects, which are several layers of abstractions further from the problem here
1 reply 0 retweets 2 likes
secret-dependent lookups are the converse problem: people writing security code not being aware of the underlying implications of how CPUs do thing. The problem is the stack is way too fucking deep.
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.