On Sat, Feb 12, 2022 at 06:05:54PM -0500, Joshua Kinard wrote:
On 2/11/2022 16:07, Jason A. Donenfeld wrote:
This is very much an RFC patch, or maybe even an RFG -- request for
grumbles. This topic has come up a million times, and usually doesn't go
anywhere. This time I thought I'd bring it up with a slightly narrower
focus. Before you read further, realize that I do not intend to merge
this without there being an appropriate amount of consensus for it and
discussion about it.
Ever since Linus' 50ee7529ec45 ("random: try to actively add entropy
rather than passively wait for it"), the RNG does a haveged-style jitter
dance around the scheduler, in order to produce entropy (and credit it)
for the case when we're stuck in wait_for_random_bytes(). How ever you
feel about the Linus Jitter Dance is beside the point: it's been there
for three years and usually gets the RNG initialized in a second or so.
What about the case where a small amount of entropy is avalable?
As a matter of fact, this is what happens currently when people use
getrandom(2).
So, given that the kernel has grown this mechanism for seeding itself
from nothing, and that this procedure happens pretty fast, maybe there's
no point any longer in having /dev/urandom give insecure bytes. In the
past we didn't want the boot process to deadlock, which was
understandable. But now, in the worst case, a second goes by, and the
problem is resolved. It seems like maybe we're finally at a point when
we can get rid of the infamous "urandom read hole".
Why not keep the distinction between /dev/random and /dev/urandom when a
good entropy source is not avalable?
Maybe. And this is why this is a request for grumbles patch: the Linus
Jitter Dance relies on random_get_entropy() returning a cycle counter
value. The first lines of try_to_generate_entropy() are:
stack.now = random_get_entropy();
/* Slow counter - or none. Don't even bother */
if (stack.now == random_get_entropy())
return;
So it would appear that what seemed initially like a panacea does not in
fact work everywhere. Where doesn't it work?
On every platform, random_get_entropy() is connected to get_cycles(),
except for three: m68k, MIPS, and RISC-V.
[snip]
I think what this adds up to is that this change would positively affect
everybody, except for _possibly_ negatively affecting poorly configured
non-Amiga m68k systems and the MIPS R6000 and R6000A. Does that analysis
seem correct to folks reading, or did I miss something?
Are there other cases where the cycle counter does exist but is simply
too slow? Perhaps some computer historians can chime in here.
[snip]
This should realy be a config flag. (URANDOM_SECURE_RANDOM?).
--
Joshua Kinard
Gentoo/MIPS
kumba@xxxxxxxxxx
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
