Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5712037ybe; Tue, 17 Sep 2019 12:13:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqwAlUw4OhKpUexw6PwXAZOoawX+X/Qc/WSZP+3B1xY56eJiUYlOUDsiatBjbLC0xJ2GTl/9 X-Received: by 2002:a50:a939:: with SMTP id l54mr6397733edc.214.1568747622503; Tue, 17 Sep 2019 12:13:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568747622; cv=none; d=google.com; s=arc-20160816; b=aCjhqIhITVsz8syc2MzAJcQ1cYZ79WDh40SlEAPL2DOEuYAqjz0GYn8Ix7UOyftpmU badskZU5CwCRrpT2AUNNn4Kq0hiNWUQ4gwoUddRNFA3sk8oqXifYIKjb+Yjsd6ziltc6 tIkuA1sXEQO1V63jWv8OCjqhXEr6YlEiCXwJC86+oHg2XJRsUjNmS+TjzCOgU8DrEY/o 1GFDcE/Z+EMZYF0FeDUUxuAPFwbk0hM89UO4lykmNarGOy1V7i693Lx2zKB5dtxRZegF qtqH7U/FfhNG/0soIdbDo8NRirTqY44FHZ5h/VuAT77Dh5dQus1ev6/TB8jYfdQOxTb/ s+3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=7stFODLmGFpBm5m+1MWr1jb+nVahUY6L8dCExvdi6Vs=; b=wv9zD7GRXr1DE1c2Ow1ld3iDfaFTmha3KfpS3GtB3vDzG0fVZI+RCH4peK40p2y4vn 73XORmk59ndjKg+uJRvL0bFF0hGLWlK9DW1lwNFrkH4mcNSvZUKRw8JvhubcihO/EgCD ln0PPlpZLGAg32uO+JQn4JB5lPWH/HfhhbC8LjKP3ibQM8c7db1ZoCiy8OK1SSH4eND6 PgM6riMnbdsMMEscG2G2WTUaXcPTeBIMGkII9iIWX9RtyIda4ZhTrRmj4FNSrExoBtFH dTl9kP14BFJ1wteXR61MgtxuquO2p2VxELUHQ1fMWqvrjsEeLQSj00/DA1I4Zzm+yLTR PT6w== 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 p9si1954267edx.273.2019.09.17.12.13.18; Tue, 17 Sep 2019 12:13:42 -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 S1726918AbfIQR3y (ORCPT + 99 others); Tue, 17 Sep 2019 13:29:54 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:47192 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725917AbfIQR3y (ORCPT ); Tue, 17 Sep 2019 13:29:54 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x8HHTThI028042; Tue, 17 Sep 2019 19:29:29 +0200 Date: Tue, 17 Sep 2019 19:29:29 +0200 From: Willy Tarreau To: Lennart Poettering 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: <20190917172929.GD27999@1wt.eu> References: <20190917052438.GA26923@1wt.eu> <2508489.jOnZlRuxVn@merkaba> <20190917121156.GC6762@mit.edu> <20190917155743.GB31567@gardel-login> <20190917162137.GA27921@1wt.eu> <20190917171328.GA31798@gardel-login> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190917171328.GA31798@gardel-login> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Sep 17, 2019 at 07:13:28PM +0200, Lennart Poettering wrote: > On Di, 17.09.19 18:21, Willy Tarreau (w@1wt.eu) wrote: > > > On Tue, Sep 17, 2019 at 05:57:43PM +0200, Lennart Poettering wrote: > > > Note that calling getrandom(0) "too early" is not something people do > > > on purpose. It happens by accident, i.e. because we live in a world > > > where SSH or HTTPS or so is run in the initrd already, and in a world > > > where booting sometimes can be very very fast. > > > > It's not an accident, it's a lack of understanding of the impacts > > from the people who package the systems. Generating an SSH key from > > an initramfs without thinking where the randomness used for this could > > come from is not accidental, it's a lack of experience that will be > > fixed once they start to collect such reports. And those who absolutely > > need their SSH daemon or HTTPS server for a recovery image in initramfs > > can very well feed fake entropy by dumping whatever they want into > > /dev/random to make it possible to build temporary keys for use within > > this single session. At least all supposedly incorrect use will be made > > *on purpose* and will still be possible to match what users need. > > 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. It's not because people got used to doing things the wrong way by ignorance of how randomness works and raised this to an industrial level that they must not adapt a little bit. If they insist on producing an SSH key immediately at boot, you can be sure that many of those that never fail are probably bad because they probably used some of the tricks mentioned in this thread (like the fairly common mknod trick that can make sense in a temporary system installation image) :-/ I maintain that we don't need the same amount of entropy to run a regular system and to create a new key, and that as such it is not a reasonable thing to do to create such a key as the first action. I'm not saying that doing things correctly is as easy, but it's not impossible at all: many of us have already used systems which use something like dropbear with temporary key on the install image but run off openssh in the final system image. And even when booting off a pre-configured final image we could easily imagine that the ssh service detects lack of entropy and runs with a temporary key that is not saved, and in the background starts a process trying to produce a final key for later use. Willy