[PATCH 1/1] efi_leader: delete rng-seed if having EFI RNG protocol

[Simon Glass]

Hi,

On Thu, 19 Sept 2024 at 17:37, Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> On Thu, 19 Sept 2024 at 18:19, Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi,
> >
> > On Thu, 19 Sept 2024 at 17:13, Ilias Apalodimas
> > <ilias.apalodimas at linaro.org> wrote:
> > >
> > >
> > >
> > > On Thu, Sep 19, 2024, 18:05 Heinrich Schuchardt <heinrich.schuchardt at canonical.com> wrote:
> > >>
> > >> On 19.09.24 17:00, Simon Glass wrote:
> > >> > Hi,
> > >> >
> > >> > On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas
> > >> > <ilias.apalodimas at linaro.org> wrote:
> > >> >>
> > >> >> Hi all,
> > >> >>
> > >> >> On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt
> > >> >> <heinrich.schuchardt at canonical.com> wrote:
> > >> >>>
> > >> >>> On 19.09.24 16:10, Simon Glass wrote:
> > >> >>>> Hi Heinrich,
> > >> >>>>
> > >> >>>> On Sat, 14 Sept 2024 at 18:06, Heinrich Schuchardt
> > >> >>>> <heinrich.schuchardt at canonical.com> wrote:
> > >> >>>>>
> > >> >>>>> For measured be boot we must avoid any volatile values in the device-tree.
> > >> >>>>> We already delete /chosen/kaslr-seed if we provide and EFI RNG protocol.
> > >> >>>>
> > >> >>>> Could you explain a bit why this is, and where this is checked?
> > >> >>>>>
> > >> >>>>> Additionally remove /chosen/rng-seed provided by QEMU or U-Boot.
> > >> >>>
> > >> >>> Measured boot relies on creating hashes of artifacts and writing these
> > >> >>> to TPM. If the hashes don't match the OS will either warn or refuse to
> > >> >>> boot. The device-tree is one of the artifacts that are measured.
> > >> >>>
> > >> >>> If we have random values in /chosen, measured boot will fail.
> > >> >>>
> > >> >>> When an EFI RNG protocol is provided by the firmware, GRUB and the
> > >> >>> kernel will use it instead of /chosen/rng-seed and /chosen/kaslr-seed.
> > >> >>
> > >> >> There's a comment on top of that function that explains what happens as well.
> > >> >> In short the EFI stub does not even look at the KASLR seed and never
> > >> >> randomizes the physical placement of the kernel. It only does that
> > >> >> when the EFI_RNG protocol is there.
> > >> >
> > >> > OK thank you. I suppose I am more just wondering why it got added in
> > >> > the first place?
> > >>
> > >> For booting via the legacy Linux entry point adding kaslr-seed allows to
> > >> randomize addresses. QEMU adds rng-seed instead of kaslr-seed.
> > >
> > >
> > > Not the kernel physical placement. It randomizes only the virtual placement
> >
> > So, are you saying that U-Boot adds this field into the FDT and then removes it?
>
> Yes. As Heinrich said, the rng seed is still usable for some
> randomization. If we boot with EFI and have an RNG protocol, we dont
> need it and it also messes up the TPM measurements, so we remove it.
> But the code that injects it to u-boot, or the prior bootloader that
> handed you over a DT,  does not know if you plan to boot with EFI.

I'm actually surprised that this works. Normally, removing a property
does not drop that property from the string table, so adding a
property and deleting it is not normally the same as never adding it.
But perhaps that has changed?

Anyway, I think we should add the property when we know it is OK to do
so, which is just before we boot. If you agree I can take a look at
that.

Regards,
Simon