Re: Linux 5.3-rc8

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux