CoCo VMs On Linux Will Now Panic If RdRand Is Broken To Avoid Catastrophic Conditions

[phoronix]

Phoronix: CoCo VMs On Linux Will Now Panic If RdRand Is Broken To Avoid Catastrophic Conditions

For confidential computing "CoCo" virtual machines where the VM host is assumed to be un-trusted and aims to be as isolated as possible, RdRand hardware random number generator instructions are one of the limited sources of entropy for guest VMs. Right now RdRand can fail and the CoCo guest VMs will continue to boot albeit with limited or no entropy to see the VM's random number generation. But being merged today as part of x86 fixes for Linux 6.9 is now requiring seeding RNG with RdRand for CoCo environments otherwise a kernel panic...

https://www.phoronix.com/news/CoCo-Linux-Require-RdRand

[alberto-pv]

"present on Intel CPUs for more than a decade (going back to Ivy Bridge when it was initially codenamed Bull Mountain) and on Intel CPUs going back a decade"

Maybe the second Intel is AMD?

[Michael]

"present on Intel CPUs for more than a decade (going back to Ivy Bridge when it was initially codenamed Bull Mountain) and on Intel CPUs going back a decade"

Maybe the second Intel is AMD?

Whoops thanks yes

[Developer12]

An untrusted host? You're insane.

[zx2c4]

An untrusted host? You're insane.

Yeah. If you look at the mailing list threads about this, that was my first instinct in my posts -- "is this threat model even real?" But I guess some people care about it.

[ssokolow]

An untrusted host? You're insane.

I assume the threat model is to protect your VPS from another tenant on the same machine making use of some kind of VM escape vulnerability to gain privilege in the host.

You trust the one who is supposed to have root on the VM host, but not anyone who might be able to gain root.

[Developer12]

I assume the threat model is to protect your VPS from another tenant on the same machine making use of some kind of VM escape vulnerability to gain privilege in the host.

You trust the one who is supposed to have root on the VM host, but not anyone who might be able to gain root.

These two scenarios are functionally indistinguishable. If another tennant takes control of the host, you're screwed.

[Developer12]

Yeah. If you look at the mailing list threads about this, that was my first instinct in my posts -- "is this threat model even real?" But I guess some people care about it.

People care about using a machine with 110% efficiency to generate Free Energy, but that doesn't mean it makes sense.

[zx2c4]

People care about using a machine with 110% efficiency to generate Free Energy, but that doesn't mean it makes sense.

I guess, but the Intel and AMD people seem to think they can eventually make it work and whack-a-mole all the various bugs and leaks, and so there's already support for these hardware features all throughout the arch/x86 code. When I get an email saying, "hey we might have this randomness problem," even if my first reply to them is, "your threat model seems bonkers, are you for real?," if they reply, "yes we are and look at this big subsystem for it," I'm not gonna say, "nah, you're stupid, don't ask me for help." That wouldn't be responsible or helpful maintainership. Rather, I wrote a fix that can live isolated in their subsystem. It's not cluttering or living in the core RNG code. It's just hanging out on an island with the other CoCo and x86 code. If they succeed with their security model, then this is a very cool feature. If they don't and they rip out all this code, my commit would be ripped out with it, and so no harm done. Does that seem reasonable?

[ssokolow]

These two scenarios are functionally indistinguishable. If another tennant takes control of the host, you're screwed.

My point was that, if the vendor were as untrustworthy as the attacker, you wouldn't sign up with them in the first place. That's the rationale behind the creation of this feature.

It it as much security theatre as KASLR? Time will tell.