> On 19 Oct 2016, at 21:20, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > 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") Uefi config tables only live in memory. They are used to provide the os with data that the firmware generates at boot, e.g., smbios and acpi tables etc >>> 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. :) > Yes, but as Mark pointed out, we need to decide how to handle kexec, which does not go through the stub -- 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
