Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp6632015ybe; Wed, 18 Sep 2019 06:42:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqxkNl2d3qKynaAoAjcAdAyLe95WvEWztNXYD2FU3JLLW5JILUibmmgn+K7ZAkT+MTFgGzKo X-Received: by 2002:a17:906:6c8:: with SMTP id v8mr9675584ejb.252.1568814164647; Wed, 18 Sep 2019 06:42:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568814164; cv=none; d=google.com; s=arc-20160816; b=Kq7F14/ApV0czg9FoNRsiqAZe7vmvvYUWxyiwCmfqA4InU+JWazPyUvnJJnGwW4wLC J5cBt7V8NrTr0lDZ3lvL1QsWOxohcr+Yva/TIobU9/KPz+1fLsVIUsbXryrKBFAQ09qj Ul8kDoBSCtVoxzLPn2mu0jm0p5q4wKFb8H1ePN9a35LBGE3HSyFFz0bEfl0Or/rSRJyX HKPtpqJzl9K7CRwuRSedge3IzaxvhByOidOBszysqzLz/Fnamb6ea9IA8/1nLtd1Fg4F xU5Wo35xxEGylpZfJq64/coyl1kUeEJ4jRakm8LVTgUOOK+nJgpmA7/XKX+SP2RQXX+O FndA== 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=tKghZgqGl5bj+C/UNuToQTWI9QGtO/S+zYa09RHendU=; b=H9etk9zJL/FphUOAXbR0DIibetKM6WLkSsTaMjtB6KcVexjTRO/16eYex5fmtGTkZZ 9xMmW4OxYAzb1hw7MsIbQb5F+5Hx6K0ufRLqcXxkypK/48Nxqsu7wwYK7lpwD9ILProM +KNFW2NL4zJgmYwt6y9JLqrIXECLUyZ+5rn3bn7hArngLd/pSGv/GvSlJcxQKwfPt7EG aekfrAK2qEpWmJwRbF0n5VCPOrjNHXt2AoE9gi0jmMxvA9UUodi7S1DKrAHCNnxsozPm hZxZntWMlQhBVtxX8VAL5LMY9fG0BvtJfoI/GDpoAtDpHRpel1HIqigDbdMHjynHToXq rTMA== 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 13si3051807edw.357.2019.09.18.06.42.20; Wed, 18 Sep 2019 06:42:44 -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 S1726961AbfIRNiJ (ORCPT + 99 others); Wed, 18 Sep 2019 09:38:09 -0400 Received: from gardel.0pointer.net ([85.214.157.71]:41602 "EHLO gardel.0pointer.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726618AbfIRNiJ (ORCPT ); Wed, 18 Sep 2019 09:38:09 -0400 Received: from gardel-login.0pointer.net (gardel.0pointer.net [85.214.157.71]) by gardel.0pointer.net (Postfix) with ESMTP id 81113E80FFC; Wed, 18 Sep 2019 15:38:07 +0200 (CEST) Received: by gardel-login.0pointer.net (Postfix, from userid 1000) id 0B989160ADC; Wed, 18 Sep 2019 15:38:06 +0200 (CEST) Date: Wed, 18 Sep 2019 15:38:06 +0200 From: Lennart Poettering To: Willy Tarreau Cc: "Theodore Y. Ts'o" , Matthew Garrett , Linus Torvalds , "Ahmed S. Darwish" , Vito Caputo , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , "Alexander E. Patrakov" , zhangjs , linux-ext4@vger.kernel.org, lkml Subject: Re: Linux 5.3-rc8 Message-ID: <20190918133806.GA32346@gardel-login> References: <20190917052438.GA26923@1wt.eu> <2508489.jOnZlRuxVn@merkaba> <20190917121156.GC6762@mit.edu> <20190917155743.GB31567@gardel-login> <20190917162137.GA27921@1wt.eu> <20190917171328.GA31798@gardel-login> <20190917172929.GD27999@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190917172929.GD27999@1wt.eu> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Di, 17.09.19 19:29, Willy Tarreau (w@1wt.eu) wrote: > > What do you expect these systems to do though? > > > > I mean, think about general purpose distros: they put together live > > images that are supposed to work on a myriad of similar (as in: same > > arch) but otherwise very different systems (i.e. VMs that might lack > > any form of RNG source the same as beefy servers with muliple sources > > the same as older netbooks with few and crappy sources, ...). They can't > > know what the specific hw will provide or won't. It's not their > > incompetence that they build the image like that. It's a common, very > > common usecase to install a system via SSH, and it's also very common > > to have very generic images for a large number varied systems to run > > on. > > I'm totally file with installing the system via SSH, using a temporary > SSH key. I do make a strong distinction between the installation phase > and the final deployment. The SSH key used *for installation* doesn't > need to the be same as the final one. And very often at the end of the > installation we'll have produced enough entropy to produce a correct > key. That's not how systems are built today though. And I am not sure they should be. I mean, the majority of systems at this point probably have some form of hardware (or virtualized) RNG available (even raspi has one these days!), so generating these keys once at boot is totally OK. Probably a number of others need just a few seconds to get the entropy needed, where things are totally OK too. The only problem is systems that lack any reasonable source of entropy and where initialization of the pool will take overly long. I figure we can reduce the number of systems where entropy is scarce quite a bit if we'd start crediting entropy by default from various hw rngs we currently don't credit entropy for. For example, the TPM and older intel/amd chipsets. You currently have to specify rng_core.default_quality=1000 on the kernel cmdline to make them credit entropy. I am pretty sure this should be the default now, in a world where CONFIG_RANDOM_TRUST_CPU=y is set anyway. i.e. why say RDRAND is fine but those chipsets are not? That makes no sense to me. I am very sure that crediting entropy to chipset hwrngs is a much better way to solve the issue on those systems than to just hand out rubbish randomness. Lennart -- Lennart Poettering, Berlin