On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper <jason@xxxxxxxxxxxxxx> wrote: > Hey Kees, Thomas, > > On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote: >> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier <thgarnie@xxxxxxxxxx> wrote: >> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper <jason@xxxxxxxxxxxxxx> wrote: >> >> Hey Kees, >> >> >> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote: >> >>> Notable problems that needed solving: >> >> ... >> >>> - Reasonable entropy is needed early at boot before get_random_bytes() >> >>> is available. >> >> >> >> This series is targetting x86, which typically has RDRAND/RDSEED >> >> instructions. Are you referring to other arches? Older x86? Also, >> >> isn't this the same requirement for base address KASLR? >> >> >> >> Don't get me wrong, I want more diverse entropy sources available >> >> earlier in the boot process as well. :-) I'm just wondering what's >> >> different about this series vs base address KASLR wrt early entropy >> >> sources. >> >> >> > >> > I think Kees was referring to the refactor I did to get the similar >> > entropy generation than KASLR module randomization. Our approach was >> > to provide best entropy possible even if you have an older processor >> > or under virtualization without support for these instructions. >> > Unfortunately common on companies with a large number of older >> > machines. >> >> Right, the memory offset KASLR uses the same routines as the kernel >> base KASLR. The issue is with older x86 systems, which continue to be >> very common. > > We have the same issue in embedded. :-( Compounded by the fact that > there is no rand instruction (at least not on ARM). So, even if there's > a HW-RNG, you can't access it until the driver is loaded. > > This is compounded by the fact that most systems deployed today have > bootloaders a) without hw-rng drivers, b) without dtb editing, and c) > without dtb support at all. > > My current thinking is to add a devicetree property > "userspace,random-seed" <address, len>. This way, existing, deployed > boards can append a dtb to a modern kernel with the property set. > The factory bootloader then only needs to amend its boot scripts to read > random-seed from the fs to the given address. The arm64 KASLR implementation has defined a way for boot loaders to pass in an seed similar to this. It might be nice to have a fall-back to a DT entry, though, then the bootloaders don't need to changed. Ard might have some thoughts on why DT wasn't used for KASLR (I assume the early parsing overhead, but I don't remember the discussion any more). > Modern systems that receive a seed from the bootloader via the > random-seed property (typically from the hw-rng) can mix both sources > for increased resilience. Yeah, that could work. > Unfortunately, I'm not very familiar with the internals of x86 > bootstrapping. Could GRUB be scripted to do a similar task? How would > the address and size of the seed be passed to the kernel? command line? Command line could work (though it would need scrubbing to avoid it leaking into /proc/cmdine), but there's also the "zero-page" used by bootloaders to pass details to the kernel (see Documentation/x86/boot.txt). Right now, x86 has sufficient entropy (though rdrand is best). -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
