lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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 <>,,
        lkml <>
Subject: Re: Linux 5.3-rc8

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.


Powered by blists - more mailing lists