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