[PATCH] efi_loader: Get rid of kaslr-seed

[Ilias Apalodimas]

Hi Mark, 

On Thu, Dec 16, 2021 at 04:48:04PM +0100, Mark Kettenis wrote:
> > From: Ard Biesheuvel <ardb at kernel.org>
> > Date: Thu, 16 Dec 2021 16:28:06 +0100
> > 
> > On Thu, 16 Dec 2021 at 16:25, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> > >
> > > > From: Ilias Apalodimas <ilias.apalodimas at linaro.org>
> > > > Date: Thu, 16 Dec 2021 16:52:08 +0200
> > > >
> > > > Right now we unconditionally pass a 'kaslr-seed' property to the kernel
> > > > if the DTB we ended up in EFI includes the entry.  However the kernel
> > > > EFI stub completely ignores it and only relies on EFI_RNG_PROTOCOL.
> > > > So let's get rid of it unconditionally since it would mess up the
> > > > (upcoming) DTB TPM measuring as well.
> > >
> > > NAK

I don't understand why though.  I can simply send a V2 and have a Kconfig
e.g CONFIG_MEASURE_DTB, which would control stripping the property -- or we 
could save- > strip -> measure -> re-inject (which is a horrible idea but 
that's the current reality).

> > >
> > > OpenBSD uses the kaslr-seed property in the bootloader to mix in some
> > > additional entropy.  (It will also use EFI_RNG_PROTOCOL if it is
> > > avilable, but most U-Boot boards don't provide that, or at least not
> > > yet).
> > >
> > 
> > What is the point of using both the DT property and the protocol if
> > both are available?
> 
> Unless kaslr-seed is coming from a different entropy source, there
> probably isn't a point.  But it doesn't hurt and it made the
> bootloader code simpler.

It does hurt the measurements though.  The current situation is a bit
weird.  Ideally the firmware would provide the DTB and I would be be able
to measure prior to any fixups.  However that's not the reality today.  So
we do have to measure just before we install the config table.  Which means
that all entries that can change across reboots needs to be ignored.

> 
> It does mean there is some room for compromise though.  If U-Boot
> would only remove kaslr-seed if it implements EFI_RNG_PROTOCOL it
> wouldn't be a problem.
> 
> > > Even on Linux the EFI stub isn't the only way to load a Linux kernel.
> > > You can use a conventional EFI bootloader like grub.
> > >
> > 
> > No, you cannot, at least not on architectures other than x86. GRUB on
> > ARM always boots via the EFI stub.
> 
> Ok.  It isn't immediately clear from the documentation that this is
> the case.  It would still be possible to write such a bootloader, but
> if it isn't a thing, it isn't a thing.  But not all the world is
> Linux.

Yea but measuring is a reality (and a spec for all it matters).  So we need
to find some way of fixing this.

Regards
/Ilias