Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp6425046ybe; Wed, 18 Sep 2019 03:18:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqx5fyBSluowpF8txkKylkMSntRIzH6N0MO3QfOgfCy/clyYb00tbWw9NH1y2elHezccaebn X-Received: by 2002:a17:906:b34c:: with SMTP id cd12mr8818936ejb.48.1568801913015; Wed, 18 Sep 2019 03:18:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568801913; cv=none; d=google.com; s=arc-20160816; b=RWkR+iMdjSg8vZm9cp7sM9ebkwKriuioI3drurlEzM9GhMyrrcjdcbk4cGn5lfMNK8 yqOmffTHPxVptrgBIcubQ8sdzrTRfQXSXkWaZqoiDxfPo6xIy40P2prE21+LElrSLp9i 2yLPZYts1I4YqJTmiagqQwwgtf0YuxYnWqVlCXqyXucK4gy/DRlxF8UItgrjubCiHHGK dWdohZUGbaLqVTy8fO6hY22qvS3TPOuASRXNlDpKTgLxmnCqrLYbKIOBchkmS48A1z6I RwCLX3Bd0v8arbnYO0J1W+gNxjKyKeNSyLzvyjd2FTqOwLrqA94xUCQGCSRIJHAfVMvY 45Og== 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=gtVjiPBdZVixoVV4c6JNCbMjTVsKbsfcPxxGeL76pfA=; b=Zhtjd4dqKN8N4QE7+3y682maVThpVlkXqaCSpD1KZ/OvY2Wuaky3BsiYi0Vvy667kj fl6Gv6uaPOBNmAqk1nCcj1als6KCaX9vvF0ogJyHi2NJ/qYxx+jm2eyDaNqW0UQggdwL bNDNs3f6pSx/o6Z/ZGylPW8/8IWZqlDWS8bdDGEE9yhJQTvwJPivhsdxSx0vsM+MAZwm KmPgorcIRsfJapz2ZUCMnG1yIe+rrjROxuBKOtUrc1rUokQLb+e3TiZ6bB/BIQwhOJvI hjHlgwfvJyrPXcPNMuDhj8U7FDPVtQ4Z9mhNeaYCKqDZEyaoN7tvLE43WsMXLxWbofu7 Inwg== 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 n4si2308090ejj.132.2019.09.18.03.18.04; Wed, 18 Sep 2019 03:18:33 -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 S1729478AbfIRKQu (ORCPT + 99 others); Wed, 18 Sep 2019 06:16:50 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:47697 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729128AbfIRKQu (ORCPT ); Wed, 18 Sep 2019 06:16:50 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x8IAGGrf029569; Wed, 18 Sep 2019 12:16:16 +0200 Date: Wed, 18 Sep 2019 12:16:16 +0200 From: Willy Tarreau To: Rasmus Villemoes Cc: Linus Torvalds , Lennart Poettering , "Ahmed S. Darwish" , "Theodore Y. Ts'o" , Matthew Garrett , 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: <20190918101616.GA29565@1wt.eu> References: <20190917052438.GA26923@1wt.eu> <2508489.jOnZlRuxVn@merkaba> <20190917121156.GC6762@mit.edu> <20190917123015.sirlkvy335crozmj@debian-stretch-darwi.lab.linutronix.de> <20190917160844.GC31567@gardel-login> <20190917174219.GD31798@gardel-login> <89aeae9d-0bca-2a59-5ce2-1e18f6479936@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89aeae9d-0bca-2a59-5ce2-1e18f6479936@rasmusvillemoes.dk> 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 Wed, Sep 18, 2019 at 11:33:39AM +0200, Rasmus Villemoes wrote: > On 17/09/2019 22.58, Linus Torvalds wrote: > > Side note, and entirely unrelated to this particular problem, but > > _because_ I was looking at the entropy init and sources of randomness > > we have, I notice that we still don't use the ToD clock as a source. > > And unrelated to the non-use of the RTC (which I agree seems weird), but > because there's no better place in this thread: How "random" is the > contents of RAM after boot? Sure, for virtualized environments one > probably always gets zeroed pages from the host (otherwise the host has > a problem...), and on PCs maybe the BIOS interferes. > > But for cheap embedded devices with non-ECC RAM and not a lot of > value-add firmware between power-on and start_kernel(), would it make > sense to read a few MB of memory outside of where the kernel was loaded > and feed those to add_device_randomness() (of course, doing it as early > as possible, maybe first thing in start_kernel())? Or do the reading in > the bootloader and pass on the sha256() in the DT/rng-seed property? > > A quick "kitchen-table" experiment with the board I have on my desk > shows that there are at least some randomness to be had after a cold boot. > > Maybe this has already been suggested and rejected? We've already discussed that point a few times. The issue is that bootloaders and/or BIOSes tend to wipe everything. Ideally we should let the boot loader collect entropy from the DDR training phase since it's a period where noise is observed. It's also the right moment to collect some random contents that may lie in the RAM cells. Similarly asynchronous clocks driving external components can be used as well if you can measure their phase with the CPU's clock. Regards, Willy