[PATCH] efi_loader: Get rid of kaslr-seed

[Heinrich Schuchardt]

On 12/16/21 16:48, Mark Kettenis wrote:
>> From: Ard Biesheuvel <ardb at kernel.org>
>> Date: Thu, 16 Dec 2021 16:28:06 +0100
>>
>> On Thu, 16 Dec 2021 at 16:25, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>>>
>>>> From: Ilias Apalodimas <ilias.apalodimas at 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.