On Thu, 16 Dec 2021 at 18:55, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > From: Ard Biesheuvel <a...@kernel.org> > > Date: Thu, 16 Dec 2021 18:12:02 +0100 > > > > On Thu, 16 Dec 2021 at 17:56, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > > > > > From: Ard Biesheuvel <a...@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.apalodi...@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.apalodi...@linaro.org> > > > > > > > > Acked-by: Ard Biesheuvel <a...@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.
