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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ