Re: the entropy bug, and device timeouts (was: Note: two files changed and hashes/signatures updated for NetBSD 8.1)

[David Brownlee <abs%absd.org@localhost>]

On Tue, 1 Feb 2022 at 23:31, Greg A. Woods <woods%planix.ca@localhost> wrote:
>
> At Thu, 27 Jan 2022 10:40:20 +0100, Martin Husemann <martin%duskware.de@localhost> wrote:
> Subject: Re: the entropy bug, and device timeouts (was: Note: two files changed and hashes/signatures updated for NetBSD 8.1)
> >
> > On Wed, Jan 26, 2022 at 10:56:53PM -0800, Greg A. Woods wrote:
> > > Well, if you have a hardware RNG, or my patches, then that'll do
> > > something, but otherwise it's just useless noise and misdirection.
> >
> > This is not true. Once there is enough entropy gathered (or the system
> > has been told the administrator considers it good enough), everything is
> > fine and basically the same state as before the changes you want to back
> > out (at least from a userland perspective).
>
> That's not my experience, though I am not quite at -current.
>
> One thing that I found I had to change was the way feeding a random
> number as entropy through /dev/random wasn't working unless I re-enabled
> so-called "estimation" for that device (via rndctl), and I don't think
> that was due to any of my changes.
>
> Note that the "seed" device is trusted in the code as if it were a
> hardware random number generator so it has "collection" and "estimation"
> enabled by default.
>
> Keep in mind also that not all ways of booting NetBSD allow for
> "rndseed", including Xen domUs.
>
> What my patches do is re-enable the ability of rndctl to (re-)enable
> "collection" and/or "estimation" for other devices that have calls to
> submit values and/or timestamps to entropy collection.
>
> This means the following can be added to /etc/rc.conf on, for example,
> Xen domU systems and they can come up to full entropy in the good old
> fashioned way without suffering from lack of any way to insert entropy
> with "rndseed":
>
>         rndctl=YES      rndctl_flags="-t disk; -t vm" # optional: "-t net"
>
> I have some tentative patches to make this all actually work for domUs
> in sysinst too in the way your message discussed, but I've had a
> extremely difficult time getting that to work in any kind of
> user-friendly way.  It took hours of code walk-through just to figure
> out what was really expected of the user.  Also for other reasons
> (e.g. cloning domUs), I think the "rndctl" way is both easier and more
> secure (assuming all the regular things about security between domUs on
> the same server).
>
> My patches also mean systems without hardware RNG devices can do the
> same, and indeed my Dell servers do just fine accumulating their own
> entropy after boot without rndseed and without even any "rndctl" setup
> as they have fan speed and voltage monitors in their environmental
> sensors, and my patches re-enable default collection and estimation for
> such trusted devices.
>
> Personally I find the way the current kernel handles entropy,
> i.e. without my patches, to be obnoxious, condescending, and ignorant.
> Perhaps that view might cause some to consider me to be the same way,
> but I can easily live with that.

I was not involved in any of it, but I rather like the more rigorous
approach to random number quality, rather than the previous finger in
the air "We've had enough of some bits of unknown quality in, so maybe
we're good?" trigger. (On the other hand I'm pretty sure I hit
obnoxious, condescending, and/or ignorant on at some issues, whether
or not this is in that set)

If the intent is to be more rigorous regarding random number quality,
so systems with high quality sources Just Work, then those without
need someone to make two decisions:

- load a high quality seed from another system
or
- copy something into /dev/urandom as root to seed (which can be data
from urandom if not concerned about random quality)

plus

- Run "/etc/rc.d/random_seed stop" to persist the seed
or
- Setup to repeat the seed on each boot

AFAIU all systems should continue to accumulate data from random
sources to mix into the pool, it's just there is an additional check
as to whether a pool has sufficient genuine entropy to be considered
good enough to generate /dev/random

If the above is not working, then there is an implementation issue,
and it definitely needs to be addressed (PRs always welcome, patches
doubly so :-p)

Disagreements with the approach are obviously harder to resolve,
though it does occur to me that adding an rc.conf option of the form
insecure_entropy=YES to set a system to seed /dev/urandom on each boot
would simplify the situation for people playing with test boxes and
VMs without good random sources (though over time more and more VMs
are making VirtIO or RDRAND available)

David