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: Windows password security audit tool. GUI, reports in PDF.

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

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

On Mon, May 27, 2019 at 12:26:28PM +0000, Naveen Nathan wrote:
> Adds a compile-time option to ensure urandom reads block until
> the cryptographic random number generator (CRNG) is initialized.
> 
> This fixes a long standing security issue, the so called boot-time
> entropy hole, where systems (particularly headless and embededd)
> generate cryptographic keys before the CRNG has been iniitalised,
> as exhibited in the work at https://factorable.net/.
> 
> This is deliberately a compile-time option without a corresponding
> command line option to toggle urandom blocking behavior to prevent
> system builders shooting themselves in the foot by
> accidently/deliberately/maliciously toggling the option off in
> production builds.
> 
> Signed-off-by: Naveen Nathan <naveen@...tninja.net>

This is guaranteed to cause the system to fail for systems using
systemd.  (Unless you are running an x86 with random.trust_cpu=1 ---
in which case, this patch/config is pointless.)  And many embedded
systems *do* use systemd.  I know lots of people like to wish that
systemd doesn't exist, but we need to face reality.

*Seriously,* if this is something the system builder should be using,
they should be fixing userspace.  And if they care enough that they
would want to enable this patch, they could just scan dmesg looking
for the warnings from the kernel.

						- Ted