Hi Mark, On Sun, Jan 02, 2022 at 10:27:50PM +0100, Mark Kettenis wrote: > > Date: Sun, 02 Jan 2022 22:06:11 +0100 > > From: Heinrich Schuchardt <xypron.g...@gmx.de> > > > > Am 2. Januar 2022 21:50:35 MEZ schrieb Ilias Apalodimas > > <ilias.apalodi...@linaro.org>: > > >Hi Heinrich, > > > > > >> > > > > > > > > > >[...] > > > > > >> > > > > diff --git a/cmd/bootefi.c b/cmd/bootefi.c > > >> > > > > index d77d3b6e943d..57f13ce701ec 100644 > > >> > > > > --- a/cmd/bootefi.c > > >> > > > > +++ b/cmd/bootefi.c > > >> > > > > @@ -310,6 +310,8 @@ efi_status_t efi_install_fdt(void *fdt) > > >> > > > > /* Create memory reservations as indicated by the > > >> > > > > device tree */ > > >> > > > > efi_carve_out_dt_rsv(fdt); > > >> > > > > > > >> > > > > + efi_try_purge_kaslr_seed(fdt); > > >> > > >> This function should only be invoked for CONFIG_EFI_TCG2_PROTOCOL=y. > > > > > >Why? As we discussed the kernel ignores the kaslr-seed for the > > >physical randomization. The only reason we would like to keep it is > > >for the randomization of the virtual address. But if the EFI > > >RNG protocol is installed the EFI stub is already doing the right thing. > > >So I really think purging it if EFI RNG is installed is the best option > > >here (regardless of TPM measurements) > > > > > > > The only reason to delete kaslr-seed is that it conflicts with > > measured boot. If an OS prefers the RNG protocol over kaslr-seed is > > the decision of the OS and nothing U-Boot has to care about. > > But it is also up to the OS to decide whether it cares about measured > boot or not. > > > You will have to delete kaslr-seed no matter if you have a RNG > > protocol or not if and only if you want to use measured boot. > > So you shouldn't just unconditionally delete kaslr-seed if the > CONFIG_EFI_TCG2_PROTOCOL has been enabled, but only if it is actually > used... But is that even possible?
I can't think of any (sane) way to figure this out. > > So maybe you should just specify the certain properties (such as > kaslr-seed) should be skipped when calculating the hash of the device > tree. > We could, but I'd like to avoid that unless we don't have a better alternative. Thanks /Ilias
