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. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgp8e7WeSiDMp.pgp
Description: OpenPGP Digital Signature