Linux RNG Improvements Aim For Better VM Security

[phoronix]

Phoronix: Linux RNG Improvements Aim For Better VM Security

In addition to performance improvements for Linux's RNG code, Jason Donenfeld has also been working on security improvements around the kernel's random number generator code in the context of virtual machines. New patches he has been working on aim to address the issue of potentially having the same stream of random numbers when forking/cloning a VM...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-RNG-VM-Forks

[cyclistefou]

This guy seems to be doing good work. Looking forward to seeing all of this well reviewed and well settled after some time where people could iron out any outstanding issue. Seems that genuine improvements are coming, and this is good for everybody.

[Developer12]

This seems to me to be yet another example of why trying to run VMs on an untrusted hosting provider is absolute lunacy. I don't care how much support you get from the silicon vendor, you will never plug all the holes.

[zx2c4]

This seems to me to be yet another example of why trying to run VMs on an untrusted hosting provider is absolute lunacy. I don't care how much support you get from the silicon vendor, you will never plug all the holes.

Interesting consideration. Is what you have in mind something like... SEV-enabled guest is rewound and replayed several times in order to somehow cause it to transmit different data with the same key&nonce, causing catastrophic crypto failure in many cases? If so, would the guest setting bit 3 of its SEV policy block ("NOSEND") not mitigate this? Or do you have something different in mind? Anyway, I agree with you about the broad strokes that trusted guest inside of untrusted host is a pretty daunting problem.

[hotaru]

Anyway, I agree with you about the broad strokes that trusted guest inside of untrusted host is a pretty daunting problem.

it's not just a pretty daunting problem, it's an impossible problem. there are only two possible solutions: either replace the untrusted host with a trusted host, or don't trust the guest.

[Developer12]

it's not just a pretty daunting problem, it's an impossible problem. there are only two possible solutions: either replace the untrusted host with a trusted host, or don't trust the guest.

There are various schemes in varying degrees of production-readyness that essentially have the host set up the VM and start it running, but which don't give the host visibility into the VM. It's memory/disk images/etc are encrypted. Sort of like an SGX on steroids, in fact you could consider SGX to me one attempt at something like this.

There's also been on-again off-again talk about something like this for years with public computing, where you carry a storage drive around with you but can somehow trust the public computers you stick it into to not be doing anything funny (eg. they must actually run the OS image you provide, no snoop on it from outside a VM).

Frankly, I consider all permutations of this idea, where you can feel free to use someone else's computer, to be insane. Silicon vendor supported or not.