On Thu, Feb 10, 2022 at 10:41:53PM +0800, Sandy Harris wrote:
> +/**************************************************************************
> + * Load a 64-bit word with data from whatever source we have
> + *
> + * arch_get_random_long()
> + * hardware RNG
> + * emulated HWRNG in a VM
> + *
> + * When there are two sources, alternate.
> + * If you have no better source, or if one fails,
> + * fall back to get_xtea_long()
This isn't quite right. First of all arch_get_random is as much a
hardware RNG as a arch_get_random_seed. So trying to distinguish the
two here is confusing and blurs what is going on.
Secondly, arch_get_random_seed, on those platforms that have it, is
strictly better than arch_get_random. It takes more CPU cycles, and
has different security properties[1], but there's no good reason to
add complexity to alternate between the two.
[1] "RDSEED is intended for seeding a software PRNG of arbitrary
width. RDRAND is intended for applications that merely require
high-quality random numbers." --- Intel documentation
Finally, arch_get_random_seed and arch_get_random work in VM's, so
talking about "emulating HWRNG in a VM" doesn't make any sense. And
as I've mentioned in my comment on the previous patch, using a CRNG to
help seed a CRNG doesn't make any sense, and isn't worth the extra
complexity.
Also, note that as the code is currently situated there isn't any
extra "work" if CONFIG_ARCH_RANDOM is disabled. That's because
config_get_random_seed and friends are inline functions, and if it is
disabled, it will return false unconditionally, and the compiler will
optimize away the call. Also, note that on CPU architectures which
have CPU instructions ala RDREAD and RDSEED, it's rarely disabled
since it's on by default and to disable it you need to be in
CONFIG_EXPERT mode.
Cheers,
- Ted
