Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 17 Sep 2019 00:02:18 +0100
From:   Matthew Garrett <mjg59@srcf.ucam.org>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     "Theodore Y. Ts'o" <tytso@mit.edu>, Willy Tarreau <w@1wt.eu>,
        Vito Caputo <vcaputo@pengaru.com>,
        "Ahmed S. Darwish" <darwish.07@gmail.com>,
        Lennart Poettering <mzxreary@0pointer.de>,
        Andreas Dilger <adilger.kernel@dilger.ca>,
        Jan Kara <jack@suse.cz>, Ray Strode <rstrode@redhat.com>,
        William Jon McCann <mccann@jhu.edu>,
        "Alexander E. Patrakov" <patrakov@gmail.com>,
        zhangjs <zachary@baishancloud.com>, linux-ext4@vger.kernel.org,
        lkml <linux-kernel@vger.kernel.org>
Subject: Re: Linux 5.3-rc8
Message-ID: <20190916230217.vmgvsm6o2o4uq5j7@srcf.ucam.org>
References: <CAHk-=wiDNRPzuNE-eXs7QOpgPVLXsZOXEMQE9RmAWABiiZrSAQ@mail.gmail.com>
 <20190916014050.GA7002@darwi-home-pc>
 <20190916014833.cbetw4sqm3lq4x6m@shells.gnugeneration.com>
 <20190916024904.GA22035@mit.edu>
 <20190916042952.GB23719@1wt.eu>
 <CAHk-=wg4cONuiN32Tne28Cg2kEx6gsJCoOVroqgPFT7_Kg18Hg@mail.gmail.com>
 <20190916061252.GA24002@1wt.eu>
 <CAHk-=wjWSRzTjwN9F5gQcxtPkAgaRHJOOOTUjVakqP-Nzg9BXA@mail.gmail.com>
 <20190916172117.GB15263@mit.edu>
 <CAHk-=wgs65hez6ctK7J2k46BdQzvKU5avExPOTTJsZu6iqA-ow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHk-=wgs65hez6ctK7J2k46BdQzvKU5avExPOTTJsZu6iqA-ow@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

On Mon, Sep 16, 2019 at 10:44:31AM -0700, Linus Torvalds wrote:
>  - admit that the current situation actually causes problems, and has
> _existing_ bugs.
> 
>  - throw it out the window, with the timeout and big BIG warning when
> the problem cases trigger

The semantics many people want for secure key generation is urandom, but 
with a guarantee that it's seeded. getrandom()'s default behaviour at 
present provides that, and as a result it's used for a bunch of key 
generation. Changing the default (even with kernel warnings) seems like 
it risks people generating keys from an unseeded prng, and that seems 
like a bad thing?

It's definitely unfortunate that getrandom() doesn't have a GRND_URANDOM 
flag that would make it useful for the "I want some vaguely random 
numbers but I don't care that much and I don't necessarily have access 
to /dev/urandom" case, but at the moment we have no way of 
distinguishing between applications that are making this call because 
they want the semantics of urandom but need it to be seeded (which is 
one of the usecases getrandom() was introduced for in the first place) 
and applications that are making this call because it was convenient and 
the kernel usually ended up generating enough entropy in the first 
place. Given the ambiguity, I don't see an easy way to solve for the 
latter without breaking the former - and that could have some *very* bad 
outcomes.
 
-- 
Matthew Garrett | mjg59@srcf.ucam.org