<p dir="ltr"><br>
Den 24 maj 2016 7:15 em skrev "Jerry Leichter" <<a href="mailto:leichter@lrw.com">leichter@lrw.com</a>>:<br>
><br>
><br>
> >> But, honestly, I sincerely question the idea that you need random<br>
> >> numbers "early" in the boot process.<br>
> ><br>
> > The caveat here is kernel ASLR.  The address space is setup when the<br>
> > decompressor is run.  It either needs an architecture-specific function<br>
> > like RDRAND/RDSEED, or to be handed a seed by the bootloader.<br>
> ><br>
> > There's also the whole suite of kernel self-protection mechanisms like<br>
> > stack canaries and so on.<br>
> Let's think this through a bit.  Kernel ASLR, stack canaries, and so on, are there to protect against external code that finds holes.  Early during boot, *there's no external code running*.  We're before network initialization, so there's nothing coming in from the network links.  Basically, if an attacker has managed to get code running at this point during boot, you don't have much hope anyway.<br>
><br>
> So it seems to me you want to address a different issue:  Not how do I get enough randomness to set up kernel ASLR and related mechanisms early in boot, but how to I *put off* setting up kernel ASLR and related mechanisms until I have a usable source of randomness?</p>
<p dir="ltr">Let the bootloader / UEFI do it? </p>
<p dir="ltr">If the question is how to load and run code complex enough to interact with potentially arbitary hardware to fetch meaningful entropy, before the kernel has had a chance to prepare anything, without making the boot process more complex, it seems like that's the only clear answer. </p>
<p dir="ltr">The bootloader has to already know a thing or two anyway about the hardware and get a few things up and running, and letting it pass on entropy to the kernel as it loads it to memory keeps the overhead low. </p>