On Wednesday 12 February 2014 13:45:21 Jason Cooper wrote: > On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote: > > On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote: > > > I brought this up at last weeks devicetree irc meeting. My goal is to > > > provide early randomness for kaslr on ARM. Currently, my idea is modify > > > the init script to save an additional random seed from /dev/urandom to > > > /boot/random-seed. > > > > > > The bootloader would then load this file into ram, and pass the > > > address/size to the kernel either via dt, or commandline. kaslr (run in > > > the decompressor) would consume some of this randomness, and then > > > random.c would consume the rest in a non-crediting initialization. > > > > I like the idea, but wouldn't it be easier to pass actual random data > > using DT, rather than the address/size? > > I thought about that at first, but that requires either that the > bootloader be upgraded to insert the data, or that userspace is > modifying the dtb at least twice per boot. > > I chose address/size to facilitate modifying existing/fielded devices. > The user could modify the dtb once, and modify the bootloader > environment to load X amount to Y address. As a fallback, it could be > expressed on the commandline for non-DT bootloaders. Ah, so you are interested in boot loaders that can be scripted to do what you had in mind but cannot be scripted to add or modify a DT property. I hadn't considered that, but you are probably right that this is at least 90% of the systems you'd find in the wild today. Thinking this a bit further, I wonder if (at least upstream) u-boot has a way to modify DT properties in a scripted way that would allow the direct property. It sounds like a generally useful feature not just for randomness, so if that doesn't already work, maybe someone can implement it. In the simplest case, you'd only need to find the address of an existing property in the dtb and load a file to that location. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
