[PATCH] efi_loader: Get rid of kaslr-seed

[Ard Biesheuvel]

On Thu, 16 Dec 2021 at 18:55, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > From: Ard Biesheuvel <ardb at kernel.org>
> > Date: Thu, 16 Dec 2021 18:12:02 +0100
> >
> > On Thu, 16 Dec 2021 at 17:56, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> > >
> > > > From: Ard Biesheuvel <ardb at kernel.org>
> > > > Date: Thu, 16 Dec 2021 15:54:55 +0100
> > >
> > > Hi Ard, Ilias,
> > >
> > > > On Thu, 16 Dec 2021 at 15:52, Ilias Apalodimas
> > > > <ilias.apalodimas at linaro.org> wrote:
> > > > >
> > > > > 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.
> > > > >
> > > > > Signed-off-by: Ilias Apalodimas <ilias.apalodimas at linaro.org>
> > > >
> > > > Acked-by: Ard Biesheuvel <ardb at kernel.org>
> > > >
> > > > Note that the EFI stub itself does not consume the DTB /chosen entry
> > > > for its own randomness needs (i.e., the randomization of the physical
> > > > placement of the kernel, which also affects low order virtual
> > > > placement [bits 16-20]), and will blindly overwrite the seed with
> > > > whatever the EFI_RNG_PROTOCOL returns.
> > >
> > > But it will only do that if EFI_RNG_PROTOCOL is implemented and
> > > sucessfully returns some random data.  Otherwise "kaslr-seed" will
> > > survive as-is.  At least that is how I read the code in
> > > drivers/firmware/efi/libstub/fdt.c:update_fdt().
> > >
> > > And this is good.  On Apple M1 systems, the Apple bootloader actually
> > > provides a block of entropy the the kernel in their version of the
> > > device tree.  The m1n1 bootloader uses this entropy to populate the
> > > kaslr-seed property in the device tree it passes on.  And U-Boot is
> > > used to provide an EFI implementation such that we can boot a wide
> > > variety of OSes.  At this point we don't know yet whether the SoC
> > > includes an RNG that we can use to implement EFI_RNG_PROTOCOL in
> > > U-Boot.
> > >
> >
> > Wouldn't it be better to use this block of entropy to seed a DRBG and
> > subsequently use that as a source of random numbers?
>
> Hmm, I didn't consider that as an option.  We actually get 512 bits of
> entropy from m1n1, which should be good enough to seed a DRBG isn't
> it?  Not really my area of expertise though.  So I'll need some help
> here.
>

Yes, all the DRBGs defined by NIST SP800-90A take a seed in the order
of 300 - 500 bits IIRC.

On an arm64 system that implements the crypto extensions, stringing
together a couple of AES instructions to implement the AES-CTR of
flavor of DRBG should be rather straight-forward, and tiny in terms of
code size.

Of course, reusing an existing implementation would be even better but
I don't know from the top of my head if anything suitable exists under
an appropriate license that we can just drop in.