Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5790276ybe; Tue, 17 Sep 2019 13:37:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqxD7oOrVI/oFu8sfjv9ut0l4tHbC1vj4nHF19b3avWJGdD5FvXbDIiLnYtEPTpiCJew0O5T X-Received: by 2002:a05:6402:1f4:: with SMTP id i20mr6780287edy.137.1568752652963; Tue, 17 Sep 2019 13:37:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568752652; cv=none; d=google.com; s=arc-20160816; b=YdnymkEFjpSeII4Wy+UntfVnq12RAvCR7MQJkWj1CvcIMzRk8ZteMZwCX5LiVypNzO P5N9e0rp2ycVZ9QRBZPdNIQyp+kPYuJ59gn+rKa16YEU84QiqeqflalTcwR5SSBshDib WIiHa70VXGRfvNxpNsYzVdGDOUxP4YOECqj2qHt0wQPBIY4kr66JRUTkNZae+jQ5KA3S JhsUxK1DziDSUqEcPTyjImKYWIerM7450aA+mQ1x/Lr9u7De4Vj7PngR/cmDueaEHJlp jc2YARe8eDCxR1Qzk8QcujeMUcGjImy+GSTUEffIE6uWOUwOJEj2R7wxwvMoUZFcMpcn tJ0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=Pk8KMHzW34geXiUMc1D8PMocn6hFV7N9iYqapamn51Y=; b=HTEpZ2UYXoFqiLV6+c7fmqb3JeiA9uFDu5UT43zWh60ROdz96qrqzDtEmvPPPXH+G4 +EN2TlGNfmZOmWa80oygQOKv5b83a6kUd66WA7GbRnMWxV5uimudthGbiIB+huCsfl6N 9vTxbEDaeqzU/jLHbc97xWWPsSCIGJMqLhuVOdcSt3GlKqc44ym5/Dlzw3BFWkb9cHqL RgIs2NYF4F/0G6utH/hnx6wdpEKh7XSESORRbGDVDwXfmuX+YOXXkEYumUau9f2kNB+o 1tUI+xxXfiaRz1LMuFFNdtOvP4+voGfTOErmHZhobqWtsD2VNjJ+mxqOtI6ubmlGaQwL ISFA== 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 v17si1973831eda.256.2019.09.17.13.37.05; Tue, 17 Sep 2019 13:37:32 -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 S1727462AbfIQUgs convert rfc822-to-8bit (ORCPT + 99 others); Tue, 17 Sep 2019 16:36:48 -0400 Received: from luna.lichtvoll.de ([194.150.191.11]:48921 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726668AbfIQUgr (ORCPT ); Tue, 17 Sep 2019 16:36:47 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.lichtvoll.de (Postfix) with ESMTPSA id 32FB5776DD; Tue, 17 Sep 2019 22:36:45 +0200 (CEST) From: Martin Steigerwald To: Willy Tarreau Cc: Lennart Poettering , "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 Date: Tue, 17 Sep 2019 22:36:45 +0200 Message-ID: <5330121.x9kUHU8cTX@merkaba> In-Reply-To: <20190917162137.GA27921@1wt.eu> References: <20190917155743.GB31567@gardel-login> <20190917162137.GA27921@1wt.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" Authentication-Results: mail.lichtvoll.de; auth=pass smtp.auth=martin smtp.mailfrom=martin@lichtvoll.de Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Willy Tarreau - 17.09.19, 18:21:37 CEST: > 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. Well I wondered before whether SSH key generation for cloud init or other automatically individualized systems could happen in the background. Replacing a key that would be there before it would be replaced. So SSH would be available *before* the key is regenerated. But then there are those big fast man in the middle warnings… and I have no clear idea to handle this in a way that would both be secure and not scare users off too much. Well probably systems at some point better have good entropy very quickly… and that is it. (And then quantum computers may crack those good keys anyway in the future.) -- Martin