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