Re: getrandom and getentropy

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Sun, May 10, 2020 at 05:23:37AM +0000, Taylor R Campbell wrote:
> > 
> > >(Obviously, it is possible to run a kernel with an /etc/rc script that
> > >skips loading the seed from disk altogether; I'm not considering weird
> > >customized installations like that.  System engineers who futz with
> > >this are responsible for getting the details right.)
> > 
> > Like installing a system from read-only media or a system that crashed
> > and starts again with the same seed.
> 
> This is why:
> 
> - rndctl -L ignores entropy estimates in seeds on read-only media

Doesn't that mean that your (un-)blocking criteria will never be met ?


> Can this go wrong?  Sure, and we can discuss ways to make it more
> reliable if you like.  But my point here was not to get into all the
> details of how the seed saving and restoring process works.

The point should be why you trust file contents more than a random
process.

I can understand that the quality of random processes can be weak, in
particular in an automated or emulated scenario. But in exactly these
scenarios trusting an external source like a persisent file is much
weaker.



> My point was to compare the different processes and blocking criteria
> across different operating systems

You just changed the behaviour for NetBSD.


> > I'm wondering, how you can trust a god-sent file from persistent storage
> > but not an unspecified random process?
> 
> I don't know what you mean by this.

entropy file:   god sent information with no known entropy at all.
random process like sensor values or keyboard input: likely to be random.


> NetBSD-current counts the entropy
> specified by HWRNG drivers when they do rnd_add_data(rs, buf, len,
> entropybits), and counts data you write to /dev/random as if it came
> from a process with full entropy;

It counted an estimated entropy from other random sources before.
"Fantasized" was your word, but as fantasized as assuming a file
had full entropy.


> But how is this question relevant to the discussion at hand of whether
> to adopt a de facto standard C API or which?

It isn't. 


> > >(Obviously, it is possible to run a kernel with an /etc/rc script that
> > >skips loading the seed from disk altogether; I'm not considering weird
> > >customized installations like that.  System engineers who futz with
> > >this are responsible for getting the details right.)

Your argument was about not caring about "system engineers that futz
around" (whatever that means). If that should be the basis for an API
decision, it should be thought about.

Otherwise we just need the API that helps in running foreign (aka Linux)
software and we don't have to talk about the quality.


Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."