linux-kernel - Re: Re: [PATCH RFC v0] random: block in /dev/urandom

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 1 Mar 2022 11:27:16 -0800
From:   10maurycy10@...il.com
To:     linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org
Cc:     linux-m68k@...ts.linux-m68k.org, linux-mips@...r.kernel.org
Subject: Re: Re: [PATCH RFC v0] random: block in /dev/urandom

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@...too.org
> 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