At Mon, 05 Apr 2021 00:07:49 +0200 (CEST), Havard Eidnes <he%uninett.no@localhost> wrote: Subject: Re: regarding the changes to kernel entropy gathering > > Indeed, that's also compatible with what I wrote. The samples > from whatever sources you have are still being mixed into the > pool, but they are not being counted as contributing to the > entropy estimate, because the quality of the samples is at best > unknown. Perhaps we're talking past each other? Until I made the fix no amount of time or activity or of me telling the system to make use of the driver inputs was unblocking getrandom(2) or /dev/random, so it doesn't really matter if anything was being "mixed into the pool" so to speak as the pool was empty. > A possible workaround is, once you have some uptime and some bits > mixed into the pool, you can do: I don't need a work-around -- I found a fix. I corrected some code that was purposefully ignoring my orders for how it should behave. > I am still of the fairly firm beleif that the mistrust in the > hardware vendors' ability to make a reasonable and robust > implementation is without foundation. Well there are still millions of systems out there without the fancy newer hardware RNGs available to make them more secure than Fort Knox. At least a small handful of them run NetBSD for me, and want them to work for my needs and I was, and am, quite happy with using entropy that can be collected from various devices that my systems (virtual and real) actually have. -- 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:
pgpa3lEFTVuZU.pgp
Description: OpenPGP Digital Signature