[PATCH] efi_loader: Get rid of kaslr-seed

[Ilias Apalodimas]

Hi,

On Thu, 16 Dec 2021 at 21:00, Ard Biesheuvel <ardb at kernel.org> wrote:
>
> 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.

Right here's an idea.  The main problem I had here was measuring the
DTB.  But measuring means we have a TPM and if we have a TPM we have
an RNG.  So what we could do, is support EFI_RNG_PROTOCOL whenever a
TPM is there.  For those boards I can unconditionally weed out the
kaslr-seed and everyone will be happy.  It won't solve the problem of
ASLR when booting via EFI and a kaslr-seed persists, but we can always
fix that later.


Cheers
/Ilias