On 3/14/19 2:54 AM, Daniel P. Berrangé wrote: > The random interfact is pluggable with different impls though they are > chosen at build time currently. I guess we could provide an impl that > is backed by a deterministic source and require a special CLI option or > env var to switch to this insecure mode at runtime.
I would think that some of the existing users of the crypto backend would not need an insecure switch, as they're not specifically visible to the guest. E.g. crypto/block-luks.c. (Although, see below.) What I have done, and better in the now-posted v2, is copy exactly this CLI option from linux-user/main.c to system mode as well. Then, use that in only the places that are guest visible -- and currently use rand(3). So, within the instances I change, I am in all cases producing better quality random numbers than we do currently. In the case of -seed, using a Mersenne Twister algorithm instead of the rather tiny linear congruence algorithm of rand(3). In the case of no -seed, by using a cryptographic quality source. The final patch is the new ARM built-in hardware random number generation instruction. The spec for the insn requires crypto quality results (complying to NIST...). But, as previously stated, as a debugging tool we need to be able to force reproduciblity. Re-checking, I now see that the uses within hw/misc/ are in fact guest visible emulations of hardware random number generators, and so should probably be switched to use my new interface, just as with the ARM instruction. If you have a better name for "qemu_getrandom" that emphasizes this usage, I'm happy to change that. r~
