Hector Martin

Because now you're broadcasting extremely sensitive data (as in: all your private keys are belong to us) intended for one core to all cores. That breaks down the core isolation boundary, making the security as weak as hyperthread isolation. And we know that one is really weak.

It's been this story time and time and time again. Intel CPUs have *no* security boundaries in speculation. Their only security boundary is instruction retirement. They have zero compartmentalization or defense in depth. It's insane.

Like, this is the moral equivalent of running your web Javascript VM interpreter in kernel mode - no, better, inside the hypervisor outside the guest running Chrome, because surely it has no bugs and why would you ever need any other security layers or defense mechanisms?

This is how we got "let's read data from kernel address space in user mode, who cares", "let's interpret guest virtual addresses as physical addresses when they fault, who cares", "let's feed random leftover/uninitialized buffer data into registers, who cares", all in speculation

This is just the latest instance in "Intel CPUs are information soup, and enforce zero security or data privacy boundaries anywhere, until instruction retirement".

I get the pattern as a problem obviously. I don't understand why "rdrand and cpuid share a buffer" equals "all your keys are belong to us". Surely key generation is more than `rdrand rax`?

Nah, that's a perfectly valid way of generating keys. It's also a perfectly valid way of generating random nonces for ECDSA, which, if compromised, also reveal the private key (see: PS3)

OK, I do see how that could be an issue. I will do my level best to care about this.