tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: getrandom and getentropy



> Date: Sun, 10 May 2020 04:58:23 -0000 (UTC)
> From: mlelstv%serpens.de@localhost (Michael van Elst)
> 
> riastradh%NetBSD.org@localhost (Taylor R Campbell) writes:
> 
> >(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

- rndctl -L fails noisily if anything goes wrong with updating the
  seed file -- which entails writing it and fsyncing it before
  committing it with rename.

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.

My point was to compare the different processes and blocking criteria
across different operating systems -- to show side by side any
meaningful differences in what you're guaranteed by the time NetBSD
sysctl kern.arandom returns data vs the time OpenBSD getentropy
returns data vs the time Linux getrandom(..., 0) returns data, &c., in
order to assess how best to provide consistent semantics, if we can.

> 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.  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 also records the count in the
seed file saved with rndctl -S so you can load it again with rndctl -L
if possible.

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


Home | Main Index | Thread Index | Old Index