At Mon, 05 Apr 2021 00:07:49 +0200 (CEST), Havard Eidnes <[email protected]> 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 <[email protected]>
Kelowna, BC +1 250 762-7675 RoboHack <[email protected]>
Planix, Inc. <[email protected]> Avoncote Farms <[email protected]>
pgpkw5j9Fv1Vg.pgp
Description: OpenPGP Digital Signature
