linux-ext4 - Re: [PATCH v3 0/8] Rework random blocking

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:   Thu, 9 Jan 2020 17:40:11 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Kurt Roeckx <kurt@...ckx.be>
Cc:     Stephan Mueller <smueller@...onox.de>,
        Andy Lutomirski <luto@...capital.net>,
        Andy Lutomirski <luto@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        Lennart Poettering <mzxreary@...inter.de>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Willy Tarreau <w@....eu>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        linux-man <linux-man@...r.kernel.org>
Subject: Re: [PATCH v3 0/8] Rework random blocking

On Thu, Jan 09, 2020 at 11:02:30PM +0100, Kurt Roeckx wrote:
> 
> One thing the NIST DRBGs have is prediction resistance, which is
> done by reseeding. If you chain DRBGs, you tell your parent DRBG
> that you want prediction resistance, so your parent will also
> reseed. There currently is no way to tell the kernel to reseed.

It would be simple enough to add a new flag, perhaps GRND_RESEED, to
getrandom() which requests that the kernel reseed first.  This would
require sufficient amounts of entropy in the input pool to do the
reseed; if there is not enough, the getrandom() call would block until
there was enough.  If GRND_NONBLOCK is supplied, then getrandom()
would return EAGAIN if there wasn't sufficient entropy.

Is this what you want?

What should happen if two racing processes simultaneously call
getrandom(2) with GRND_RESEED?  Do they need to be serialized with a
separate reseed for each one?  Does it matter whether, after the
reseed, some other process calling getrandom(2) manages to get output
from the CRNG before the process requesting the RESEED gets a chance
to use the reseeded CRNG?

This can all be fixed by adding more locking, of course, but then the
crazy people who think that:

      dd if=/dev/random of=/dev/sdb

needs to be able to work at HDD, SSD, or networking line speeds, will
complain that all of this locking has slowed down /dev/[u]random, and
they can't get their hundreds of megabytes/second out of the CRNG....

> I would check my own hardware if such an option was available. I
> think it can be useful to see if the current estimates in the
> kernel are conservative enough or not. But it would require that
> you can know what the entropy source is, like the keyboard or
> harddisk.

Creating such an interface is not high on my priority list.  If
someone wants to send a proposal for such an interface, followed by a
patch, I'm happy to take a look at it.  I am worried about the
potential information leakage that such an interface might provide,
though.  So at the very least, it should be something that can be
disabled via build-time config, and perhaps hidden behind
CONFIG_EXPERIMENTAL.  I really would want to make it clear that it's
only for use by experts who are interesting in tinkering, and not
something which is enabled in a distro kernel.

> I don't think we want that. As far as I know, the only reason for
> using /dev/random is that /dev/urandom returns data before it
> has sufficient entropy.

Is there any objections to just using getrandom(2)?

   	     		   	      - Ted