Hi Heinrich, On Thu, Dec 16, 2021 at 04:59:02PM +0100, Heinrich Schuchardt wrote:
On 12/16/21 16:48, Mark Kettenis wrote:
From: Ard Biesheuvel ardb@kernel.org Date: Thu, 16 Dec 2021 16:28:06 +0100
On Thu, 16 Dec 2021 at 16:25, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Ilias Apalodimas ilias.apalodimas@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
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 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.
I can limit the stripping if EFI_RNG_PROTOCOL is installed or a specific Kconfig option is selected and hopefully we can get rid of the Kconfig in the future.
Only QEMU's ARM virt machine fills kaslr-seed in the device-tree.
U-Boot injects it as well in some cases e,g sec_firmware_get_random()
[...]
Regards /Ilias