Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2768018ybe; Sun, 15 Sep 2019 00:00:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqwzU+/y57ccM7NUbVpNMKpRUwK6MeAF42nA54ONS/pgNjnIvnyBD1BcKDkSTo0Tpy3oRm+M X-Received: by 2002:a17:906:168f:: with SMTP id s15mr2319499ejd.109.1568530813993; Sun, 15 Sep 2019 00:00:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568530813; cv=none; d=google.com; s=arc-20160816; b=b6tKJEYQlPuqLSXrafqqIKBAyFJjeb67tT9OKP/0Ef0SZKiADaGhrulCkZhPaa89U2 VElL9BATqgaBKrdz+kMKTmXzYcL278yAmtfPKLZKUJXaqVRnka7AwHKWbfPeb8wAjCYE Tg2Z2h57SiumWNxVCkHKkQd0m2bvI0rsRKZG7Inv7akH6eiiOf9UPcqTGTmfNsRQuj0n 4WfO/4KBZBJh7SW4ZMiTsnESH5vndEmux3bmOmJH4bXhTqvD6NGSV0Xx1zq0fypii3Eo URsP58HfCiCR/sr3E3//Vl2GkvO2csj9DbGJDIdKxxSpa6o9VWesOELpLinqlmoshoiW Sukw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=lUOoCxGr0hKRreStmiLzUwxEyRHt+AIpNutOvvWhSXw=; b=z8ID4eep46W/4obI5mDEsvvYOUvL0HNlAMllwLpUpRaN20NEeYdrJSlMoorlPtJuce sk/LyW+nCWDJrXVTmBrNXsH9q7sVzSgC2yaOqujGUG8AqkJ5R5IgIV/VSzhoZOoJza1M SLO0JnSUp8c2Q+eDlAzlghm9GwmbQKPUe01NglFN4FKkDj6ATafa8ru+7kjJfcLgRdFM myz67n9hbrE9dhMBhUFV6clJuo5odAWX/wyWrhYTDrrKM/IPTdKVBNcyaN26yFJIB4zD NB6y9aZ4ogsqRphfnnYy0+KayrMm5TDPmv/KwiOixhyoWH+yVSSwdax+IIGUTuvyzsXN K7lw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id oy9si16887555ejb.249.2019.09.14.23.59.50; Sun, 15 Sep 2019 00:00:13 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726293AbfIOG46 (ORCPT + 99 others); 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-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@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