From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16ADDC4CEC4 for ; Wed, 18 Sep 2019 10:16:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EBB4421920 for ; Wed, 18 Sep 2019 10:16:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729669AbfIRKQu (ORCPT ); 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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