From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36814C4CEC7 for ; Sun, 15 Sep 2019 06:56:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 11F1E20830 for ; Sun, 15 Sep 2019 06:56:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727185AbfIOG46 (ORCPT ); Sun, 15 Sep 2019 02:56:58 -0400 Received: from gardel.0pointer.net ([85.214.157.71]:38262 "EHLO gardel.0pointer.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725991AbfIOG45 (ORCPT ); Sun, 15 Sep 2019 02:56:57 -0400 X-Greylist: delayed 313 seconds by postgrey-1.27 at vger.kernel.org; Sun, 15 Sep 2019 02:56:57 EDT Received: from gardel-login.0pointer.net (gardel.0pointer.net [85.214.157.71]) by gardel.0pointer.net (Postfix) with ESMTP id 51E95E811E1; Sun, 15 Sep 2019 08:56:56 +0200 (CEST) Received: by gardel-login.0pointer.net (Postfix, from userid 1000) id F3F4B160ADC; Sun, 15 Sep 2019 08:56:55 +0200 (CEST) Date: Sun, 15 Sep 2019 08:56:55 +0200 From: Lennart Poettering To: Linus Torvalds Cc: "Alexander E. Patrakov" , "Ahmed S. Darwish" , "Theodore Y. Ts'o" , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , linux-ext4@vger.kernel.org, lkml Subject: Re: Linux 5.3-rc8 Message-ID: <20190915065655.GB29681@gardel-login> References: <20190911173624.GI2740@mit.edu> <20190912034421.GA2085@darwi-home-pc> <20190912082530.GA27365@mit.edu> <20190914150206.GA2270@darwi-home-pc> <214fed0e-6659-def9-b5f8-a9d7a8cb72af@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sa, 14.09.19 09:52, Linus Torvalds (torvalds@linux-foundation.org) wrote: > On Sat, Sep 14, 2019 at 9:35 AM Alexander E. Patrakov > wrote: > > > > Let me repeat: not -EINVAL, please. Please find some other error code, > > so that the application could sensibly distinguish between this case > > (low quality entropy is in the buffer) and the "kernel is too dumb" case > > (and no entropy is in the buffer). > > I'm not convinced we want applications to see that difference. > > The fact is, every time an application thinks it cares, it has caused > problems. I can just see systemd saying "ok, the kernel didn't block, > so I'll just do > > while (getrandom(x) == -ENOENTROPY) > sleep(1); > > instead. Which is still completely buggy garbage. > > The fact is, we can't guarantee entropy in general. It's probably > there is practice, particularly with user space saving randomness from > last boot etc, but that kind of data may be real entropy, but the > kernel cannot *guarantee* that it is. I am not expecting the kernel to guarantee entropy. I just expecting the kernel to not give me garbage knowingly. It's OK if it gives me garbage unknowingly, but I have a problem if it gives me trash all the time. There's benefit in being able to wait until the pool is initialized before we update the random seed stored on disk with a new one, and there's benefit in being able to wait until the pool is initialized before we let cryptsetup read a fresh, one-time key for dm-crypt from /dev/urandom. I fully understand that any such reporting for initialization is "best-effort", i.e. to the point where we don't know anything to the contrary, but at least give userspace that. Lennart -- Lennart Poettering, Berlin