LCE: Don't play dice with random numbers

Posted Nov 21, 2012 13:04 UTC (Wed) by etienne (guest, #25256)
Parent article: LCE: Don't play dice with random numbers

> there are no tractable tests of randomness

Maybe "root" should be able to see the bare entropy source buffer and the output of the conditioner and of the CSPRNG (or what has been generated in the past) to detect "bugs"/trojan on any computer?
Security by obscurity is not good here.
Having a sysfs file to know how many times the bare entropy has been used and how many time / for how long reads to /dev/random were delayed may be good too.

> There is currently no way to invalidate the randomness pool in the clones

Opening non-blocking the file /dev/random and read it until it blocks does not work? I did not test.

to post comments

LCE: Don't play dice with random numbers

Posted Nov 21, 2012 18:45 UTC (Wed) by hpa (guest, #48575) [Link]

There is a kernel interface for this - the RNDZAPENTCNT and RNDCLEARPOOL ioctls. The problem, of course, is that this doesn't address /dev/urandom user, and the cloned kernel doesn't know that it has been cloned.

Therefore, the VMM needs to make the kernel aware that it has been cloned, and make sure the pool diverges from its clone. This can be done by injecting a unique token into the entropy pool of each of the kernel clones as well as setting the entropy count to zero via RNDZAPENTCNT.

This doesn't require any kernel changes but requires a way for the VMM to communicate with the guest and make it do so. The other option is that we add an interface to the (guest) kernel to make it possible for the VMM to do so "from underneath", without invoking guest user space.