> Date: Sun, 10 May 2020 04:58:23 -0000 (UTC) > From: mlel...@serpens.de (Michael van Elst) > > riastr...@netbsd.org (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?
