On 12/16/21 16:48, Mark Kettenis wrote:
From: Ard Biesheuvel <a...@kernel.org>
Date: Thu, 16 Dec 2021 16:28:06 +0100
On Thu, 16 Dec 2021 at 16:25, Mark Kettenis <mark.kette...@xs4all.nl> wrote:
From: Ilias Apalodimas <ilias.apalodi...@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.
Only QEMU's ARM virt machine fills kaslr-seed in the device-tree.
On QEMU the EFI_RNG_PROTOCOL is available if you call QEMU with a
virtio-rng device.
All physical devices will have an EFI_RNG_PROTOCOL if there is a driver
available and enabled in U-Boot. There are two platforms which in the
fixup phase set kaslr-seed using an SMC call but that is after the place
where Ilias's patch is removing this property.
The EFI_RNG_PROTOCOL is the standardized way to provide entropy on UEFI.
This will also work with ACPI based systems. So it would be advisable
for OpenBSD to follow this route.
Best regards
Heinrich
Even on Linux the EFI stub isn't the only way to load a Linux kernel.
You can use a conventional EFI bootloader like grub.
No, you cannot, at least not on architectures other than x86. GRUB on
ARM always boots via the EFI stub.
Ok. It isn't immediately clear from the documentation that this is
the case. It would still be possible to write such a bootloader, but
if it isn't a thing, it isn't a thing. But not all the world is
Linux.
