From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: ilias.apalodimas@linaro.org, xypron.glpk@gmx.de, agraf@csgraf.de,
u-boot@lists.denx.de
Subject: Re: [PATCH] efi_loader: Get rid of kaslr-seed
Date: Thu, 16 Dec 2021 16:48:04 +0100 (CET) [thread overview]
Message-ID: <d3cb5729087da22e@bloch.sibelius.xs4all.nl> (raw)
In-Reply-To: <CAMj1kXGxQr-M3EOX7v+miRxf5mExNZV5GX7jK_3Xy4w6v3zZCg@mail.gmail.com> (message from Ard Biesheuvel on Thu, 16 Dec 2021 16:28:06 +0100)
> 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.
> > 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.
next prev parent reply other threads:[~2021-12-16 15:48 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 [this message]
2021-12-16 15:56 ` Ilias Apalodimas
2021-12-16 15:59 ` Heinrich Schuchardt
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=d3cb5729087da22e@bloch.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=agraf@csgraf.de \
--cc=ardb@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.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