public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: ilias.apalodimas@linaro.org, agraf@csgraf.de,
	u-boot@lists.denx.de, Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH] efi_loader: Get rid of kaslr-seed
Date: Thu, 16 Dec 2021 16:59:02 +0100	[thread overview]
Message-ID: <aaa2d582-531f-2d90-d5da-4178b126fd22@gmx.de> (raw)
In-Reply-To: <d3cb5729087da22e@bloch.sibelius.xs4all.nl>

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.

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.


  parent reply	other threads:[~2021-12-16 15:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-16 14:52 [PATCH] efi_loader: Get rid of kaslr-seed Ilias Apalodimas
2021-12-16 14:54 ` Ard Biesheuvel
2021-12-16 16:56   ` Mark Kettenis
2021-12-16 17:12     ` Ard Biesheuvel
2021-12-16 17:55       ` Mark Kettenis
2021-12-16 19:00         ` Ard Biesheuvel
2021-12-16 19:53           ` Ilias Apalodimas
2021-12-16 15:25 ` Mark Kettenis
2021-12-16 15:28   ` Ard Biesheuvel
2021-12-16 15:48     ` Mark Kettenis
2021-12-16 15:56       ` Ilias Apalodimas
2021-12-16 15:59       ` Heinrich Schuchardt [this message]
2021-12-16 16:04         ` Ilias Apalodimas
2021-12-16 15:59 ` Heinrich Schuchardt
2021-12-16 16:01   ` Ilias Apalodimas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aaa2d582-531f-2d90-d5da-4178b126fd22@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=agraf@csgraf.de \
    --cc=ardb@kernel.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox