At Mon, 5 Apr 2021 15:35:12 -0400, Thor Lancelot Simon <tls%panix.com@localhost> wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> All those inputs are *already* being injected into the entropy pool. If you
> don't understand that, you need to read the code more.
I don't see how. I don't see any evidence for that happening.
So, show me how entropy is being collected in my system:
16:18 [1.793] # uptime
4:19PM up 22 days, 16:04, 2 users, load averages: 0.00, 0.00, 0.00
16:19 [1.794] # 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 = 24
16:19 [1.795] # rndctl -l
Source Bits Type Flags
ipmi0-Temp 0 env estimate, collect, v, t, dv, dt
ipmi0-Temp1 0 env estimate, collect, v, t, dv, dt
ipmi0-Temp2 0 env estimate, collect, v, t, dv, dt
ipmi0-Temp3 0 env estimate, collect, v, t, dv, dt
ipmi0-Ambient-T 0 env estimate, collect, v, t, dv, dt
ipmi0-Planar-Te 0 env estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-1 0 env estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-1 0 env estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-2 0 env estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-2 0 env estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-3 0 env estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-3 0 env estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-4 0 env estimate, collect, v, t, dv, dt
ipmi0-Status 0 ??? estimate, collect, t, dt
ipmi0-Voltage 0 power estimate, collect, v, t, dv, dt
ipmi0-Voltage1 0 power estimate, collect, v, t, dv, dt
ipmi0-Status1 0 ??? estimate, collect, t, dt
ipmi0-Intrusion 0 ??? estimate, collect, t, dt
ipmi0-Temp4 0 env estimate, collect, v, t, dv, dt
ipmi0-Temp5 0 env estimate, collect, v, t, dv, dt
ipmi0-Temp6 0 env estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-4 0 env estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-5 0 env estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-5 0 env estimate, collect, v, t, dv, dt
ipmi0-Ambient-T 0 env estimate, collect, v, t, dv, dt
ipmi0-Ambient-T 0 env estimate, collect, v, t, dv, dt
ums0 0 tty estimate, collect, v, t, dt
ukbd0 0 tty estimate, collect, v, t, dt
/dev/random 0 ??? estimate, collect, v
sd2 0 disk estimate, collect, v, t, dt
sd1 0 disk estimate, collect, v, t, dt
sd0 0 disk estimate, collect, v, t, dt
cpu0 0 vm estimate, collect, v, t, dv
hardclock 0 skew estimate, collect, t
pckbd0 0 tty estimate, collect, v, t, dt
system-power 0 power estimate, collect, v, t, dt
autoconf 0 ??? estimate, collect, t
seed 0 ??? estimate, collect, v
16:19 [1.796] # dd if=/dev/random bs=1 count=1
[ 1970935.9749573] load: 0.00 cmd: dd 14493 [entropy] 0.00u 0.00s 0% 520k
0+0 records in
0+0 records out
0 bytes transferred in 1.839 secs (0 bytes/sec)
[ 1970946.3951782] load: 0.00 cmd: dd 14493 [entropy] 0.00u 0.00s 0% 540k
0+0 records in
0+0 records out
0 bytes transferred in 12.263 secs (0 bytes/sec)
[ 1971074.4681828] load: 0.08 cmd: dd 14493 [entropy] 0.01u 0.01s 0% 540k
0+0 records in
0+0 records out
0 bytes transferred in 140.335 secs (0 bytes/sec)
... and it stays that way for, effectively, ever
After seeing this, on real hardware, I did read the code. I found a
fix. It prevents what I show above.
My fix essentially does what you suggested in your other message and
allows the administrator to, on a per-system basis, enable estimation /
counting of entropy bits from any of the available less trusted sources.
My fix might be a bit "aggressive" (even with the accompanying change to
RND_FLAG_DEFAULT), but it does what I need it to do and, if I understand
correctly, it is still far more secure than:
echo -n "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" > /dev/random
I do trust the entropy from my fans and other environmental sources, and
for most of my systems I would also trust the disk and network sources
too, even in VMs. If you can observe or influence those then you're
probably in my house already and have access to the physical hardware.
Also if I understand correctly the trick of doing "dd if=/dev/urandom
of=/dev/random bs=32 count=1" still suffers the same problem you mention
about non-hardware-RNG devices sources, even with "stirring" from these
same non-hardware-RNG sources: _when_ should it be done? When is the
pool stirred enough? IFF the entropy from non-hardware-RNG sources is
needed to "stir" the pot in the first place, then why not just "count"
it as "real" entropy and be done with it -- at least then it is obvious
when enough entropy has been gathered and the currently implemented
algorithms handle things properly and securely and all inside the
kernel. I.e. the admin doesn't have to put a "sleep 30" or whatever in
front of it and hope that's enough and that it's still not too
predictable.
--
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:
pgpyrw36EKn00.pgp
Description: OpenPGP Digital Signature