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: <20190527153549.GA17775@armakuni.lastninja.net>
Date:   Tue, 28 May 2019 01:35:51 +1000
From:   Naveen Nathan <naveen@...tninja.net>
To:     Theodore Ts'o <tytso@....edu>, 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 10:06:43AM -0400, Theodore Ts'o wrote:
>> [...] 
>
> 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.

Hence a compile-time option; systemd systems need not use it yet.
I would argue systemd needs to fix their randomness API (it's a sad
joke), and use secure randomness only where required. For example,
it is said that systemd relies on randomness to generate unique UUIDs
where a UUIDv4 would suffice. I'm happy to add a disclaimer in the
kernel config that this will break systemd.

> *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.

And I think this is the more interesting case, system builders should
ideally fix userspace and rely on getrandom (which is no different to
this compile time option). But the reality is the boot entropy hole
problem has been the source of many insecure cryptographic keys, and
this provides a simple assurance that it can no longer be the cause
of these issues (supposing good entropy is gathered).

- Naveen