At Mon, 5 Apr 2021 23:18:55 -0400, Thor Lancelot Simon <tls%panix.com@localhost> wrote: Subject: Re: regarding the changes to kernel entropy gathering > > > dd if=/dev/urandom of=/dev/random bs=32 count=1 > > It's no better. So then I would say that in fact using some less trustworthy source of randomness (e.g. environmental sensors (including audio), clock skew, disk rotational latency, etc., even network jitter if there is no other source) as the initial seed entropy _is_ better, for most situations, and perhaps for _ALL_ situations where no hardware-RNG is available or possible. Better in part because it prevents the brain-dead way of seeding, but also because it mixes real-world data in an algorithmically sound way. > But what you're missing is that neither does what you > think. When rndctl -L runs after the system comes up multiuser, all > entropy samples that have been added (which are in the per-cpu pools) > are propagated to the global pool. Every stream RNG on the system then > rekeys itself - they are _not_ just using the entropy from the seed on > disk. Even if nothing does so earlier, when rndctl -S runs as the system > shuts down, again all entropy samples that have been added (which, again, > are accumulating in the per-cpu pools) are propagated to the global pool; > all the stream RNGs rekey themselves again; then the seed is extracted. That's all great, and more or less what I've assumed from all the previous discussion.... Except.... it seems to be useless in practice without an initial seed, And the stock implementation has no possibility of ever providing an initial seed at all on its own (unlike previous implementations, and of course unlike what my patch _affords_). So, in all practical ways my two patches together (plus perhaps one or two other related changes to calls to rnd_attach_source() which don't currently use RND_FLAG_DEFAULT, such as the one in uvm_page.c), leaves the default system behaving _exactly_ the same way as before, but for the fact that now "rndctl -e -d blah" actually does something useful and doesn't lie about what it has done and the kernel doesn't lie about what it has been told to do, and in fact entropy can be gathered and used on systems that don't have hardware RNG devices/instructions. No change in default security as compared to before the patches. I.e. the patched system still won't "estimate"/"count" any entropy bits from any untrusted (non-hardware-RNG) devices. No less secure than any earlier releases (i.e. from before the entropy re-tooling) if the admin does decide to gather entropy the old way from untrusted devices. (with the caveat that device drivers are no more aggressive about offering entropy bits to be counted than they should be) No hacks required for systems without hardware-RNGs -- just a simple config line in /etc/rc.conf. No lies from, or apparent bugs in, the kernel. No other changes required. > It is neither the case that samples added with a 0 entropy estimate go > nowhere, nor that they do not add entropy to the seed file such that it > is _not_ "reusing the same entropy on every boot". This is good, but, again, useless if there's no seed in the first place. > If you'd like to propagate samples from the per-CPU pool to the global > pool and force the stream generators to rekey more often, you can > sysctl -w kern.entropy.consolidate=1 from cron. So, are you telling me this should seed the global entropy pool from the collected samples? That's not exactly how I've understood it so far. If so this doesn't seem to do anything whatsoever, no matter how often I call it, or how long between, or how active the system is, etc., etc., etc. kern.entropy.needed never goes down, /dev/random never unblocks. 17:10 [1.804] # sysctl kern.entropy kern.entropy.collection = 1 kern.entropy.depletion = 0 kern.entropy.consolidate = -23552 kern.entropy.gather = -23552 kern.entropy.needed = 256 kern.entropy.pending = 0 kern.entropy.epoch = 26 17:10 [1.805] # sysctl -w kern.entropy.consolidate=1 kern.entropy.consolidate: 0 -> 1 17:10 [1.806] # sysctl kern.entropy kern.entropy.collection = 1 kern.entropy.depletion = 0 kern.entropy.consolidate = -23552 kern.entropy.gather = -23552 kern.entropy.needed = 256 kern.entropy.pending = 0 kern.entropy.epoch = 27 17:10 [1.807] # uptime 4:57PM up 23 days, 16:42, 2 users, load averages: 0.01, 0.01, 0.00 BTW, there seems to be a bug somewhere too since when I set it the change is "0 -> 1", but when I view it the value is always some incomprehensible meaningless negative number. # sysctl -M kern.entropy kern.entropy (1.1260): CTLTYPE_NODE, children 7/8, size 96, flags 0x0<READONLY>, ver=431 kern.entropy.collection (1.1260.1261): CTLTYPE_BOOL, size 1, flags 0x70<READWRITE>, ver=425 kern.entropy.depletion (1.1260.1262): CTLTYPE_BOOL, size 1, flags 0x70<READWRITE>, ver=426 kern.entropy.consolidate (1.1260.1263): CTLTYPE_INT, size 4, flags 0x70<READWRITE>, func=0xffffffff8083f151, ver=427 kern.entropy.gather (1.1260.1264): CTLTYPE_INT, size 4, flags 0x70<READWRITE>, func=0xffffffff8083dd4c, ver=428 kern.entropy.needed (1.1260.1265): CTLTYPE_INT, size 4, flags 0x100<READONLY,PRIVATE>, ver=429 kern.entropy.pending (1.1260.1266): CTLTYPE_INT, size 4, flags 0x100<READONLY,PRIVATE>, ver=430 kern.entropy.epoch (1.1260.1267): CTLTYPE_INT, size 4, flags 0x100<READONLY,PRIVATE>, ver=431 Perhaps function pointer values shouldn't be printed as integers? And there are no text descriptions for some of the kern.entropy values: 17:27 [1.831] # sysctl -d kern.entropy.needed kern.entropy.needed: (no description) 17:27 [1.832] # sysctl -d kern.entropy.pending kern.entropy.pending: (no description) 17:27 [1.833] # sysctl -d kern.entropy.epoch kern.entropy.epoch: (no description) -- 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:
pgplCAvqPZhkp.pgp
Description: OpenPGP Digital Signature