linux-kernel - Re: [PATCH] random: urandom reads block when CRNG is not initialized.

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 27 May 2019 13:05:39 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Naveen Nathan <naveen@...tninja.net>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kevin Easton <kevin@...rana.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] random: urandom reads block when CRNG is not initialized.

On Mon, May 27, 2019 at 05:43:03PM +0200, Jason A. Donenfeld wrote:
> 
> Really, it's a chicken & egg thing. If people who make userspaces
> never have an option to design around the correct behavior, they'll
> continue to rely on the broken behavior. But if we give them a way to
> compile their kernels with the correct behavior, eventually some
> userspaces will run fine with it. "But they should just use
> getrandom()!" you shout. Yes, and maybe the code most userspace
> builders provide does do this. But people like to plug-in plenty of
> third party things into their userspaces, and I think there's some
> value in a userspace being able to say, "we've dealt with the
> /dev/urandom situation, and we now do the right thing, so we can
> enable this option, and now the code you run on our userspace will
> give good randomness."

The challenge is that in some cases, there *is* no good solution.  If
you don't have decent hardware support, there's not a whole lot you
can do as a systems integrator or the distro.  Enabling this feature
will be a support nightmare, so I predict that darned few
distributions will be to enable it.

At the very least, we need to document the reality as it exists today,
which is that systems with systemd and Openwrt (and its derivitives),
*will* hang if this option is selected.  And we need to make sure that
zero-day testing with randconfig doesn't try to select this option
(hiding it behind CONFIG_EXPERIMENTAL should do the trick), since we
won't want to get spammed by the zero-day test bot.  That's how much
this option is guaranteed to break systems --- our continuous
integration testing systems are guaranteed to trip against it.

	    	    	    		   - Ted