RNDR/SS vs. SMCCC

[Benjamin Herrenschmidt]

On Thu, 2021-06-03 at 09:10 +0200, Ard Biesheuvel wrote:
> 
> True. However, the way things are currently set up, the hwrng is used
> both either internally (if the entropy estimate is high enough) or
> via rngd in user space to read from /dev/hwrng and write it back to
> /dev/random. This is kind of pointless in this case, although not
> harmful per se

Right. For hwrngd, we could add a flag per "source" to indicate not to
bother if we cared enough. For rngd in userspace, not much to do other
than deprecate that thing with newer kernels :-)

> > > I would be interested to hear opinions on this.
> > The issue is with things like FIPS certification (and other such
> > horrors) where I believe /dev/random is much harder to deal with
> > since
> > it mixes multiple entropy sources.
> 
> 
> /dev/random is not an entropy source but a random number generator. I
> agree with your characterization of FIPS in the general case, but the
> /dev/random kludge we have is not pretty either :-)

True :)
> 
> Note that NIST SP800-90A/B compliance has similar requirements, i.e.,
> if user space wants to seed its own DRBG in user space and comply
> with these specs, it needs a compliant entropy source as well.
> However, health tests on the entropy source are also mandated, and it
> is not clear to me how that would fit into the SMCCC + /dev/hwrng
> 
> arrangement.

Yes I'm not sure either. But having /dev/hwrng I think won't hurt
either way.

Cheers,
Ben.