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]
Message-ID: <20190527170539.GC8585@mit.edu>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ