On Wed, May 04, 2016 at 08:28:41PM -0400, Ian Sutton wrote: > This gives me an idea for how to solve the lack of a first-stage > bootloader (like biosboot(8)) on armv7. Currently U-Boot loads the > kernel image directly into memory and jmp's to its entry point without > an intermediary stage to read /etc/random.seed from disk and provide it > to the kernel to kickstart the random subsystem. I tried to solve this > problem by writing a standalone sd/mmc driver that would operate similar > to biosboot(8) in that it would first be loaded and run by U-Boot, then > read /etc/random.seed and the kernel image from the disk, load the > entropy-supplied kernel into memory and execute it. I found that each > armv7 machine's sd/mmc stack is implemented differently enough to > require a standalone driver for every vendor's armv7 toy despite SD & > MMC supposedly being "standard" interfaces. Trying to keep up with the > ever-expanding list of armv7 machines seems like a futile and inelegant > solution. > > Perhaps the entropy normally written to /etc/random.seed upon shutdown > can now be written directly to the kernel image itself, precluding the > need for such standalone drivers. I believe the reason this wasn't done > in the past was to allow checksum verification of the kernel image > between boots. With this new patch, libc.so would change between boots > precluding the possibility of such checksum verification, a contingency > I believe was properly realized and accounted for. If we can stand to > forgo the checksum verification of a big target like libc.so, perhaps we > can forgo it with the kernel image itself too and solve the boot-time > entropy problem. > > Ian >
In u-boot 2016.05 it is possible to enable EFI entry points. So the amd64 efiboot code could be adapted to read blocks that way.
