Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: regarding the changes to kernel entropy gathering



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: pgpwBvA0Gqns9.pgp
Description: OpenPGP Digital Signature



Home | Main Index | Thread Index | Old Index