On Wed, Oct 19, 2016 at 1:18 PM, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > On 19 October 2016 at 21:14, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> On Wed, Oct 19, 2016 at 4:22 AM, Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote: >>> On Wed, 19 Oct, at 12:13:55PM, Ard Biesheuvel wrote: >>>> On 19 October 2016 at 12:09, Mark Rutland <mark.rutland@xxxxxxx> wrote: >>>> >>>> > I think to some extent this mush be treated as an ABI, given cases like >>>> > kexec. >>>> > >>>> >>>> Perhaps, yes. That would also allow GRUB or other EFI aware >>>> bootloaders to generate the seed. >>> >>> If we're going to go down this route, we should try and get the GUID >>> into the UEFI spec. >> >> It seems like maybe under UEFI, both this table (which sounds like >> it'll not be rotated regularly) > > What do you mean 'rotated'? It is generated at boot. My 2/2 patch > generates it from the stub using the EFI_RNG_PROTOCOL on ARM/arm64 Oh! I entirely misunderstood. I thought doing regular writes to EFI variables was discouraged (since they may be stored in NVRAM that would "wear out"). >> could be mixed with calls to >> EFI_PROTOCOL_RNG by the kernel? (Similar to how kaslr is seeded?) >> > > That is kind of the point. KASLR is different because we need the > entropy before even jumping to C code, but for all other uses of early > entropy, this seemed like a useful approach Yup, cool. If the table changes per boot, yeah, my suggestion is pointless. :) -Kees -- Kees Cook Nexus Security -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
