From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: Ard Biesheuvel <ardb@kernel.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 17:56:03 +0200 [thread overview]
Message-ID: <Ybthk3wl3EM/wlwj@hades> (raw)
In-Reply-To: <d3cb5729087da22e@bloch.sibelius.xs4all.nl>
Hi Mark,
On Thu, Dec 16, 2021 at 04:48:04PM +0100, 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
I don't understand why though. I can simply send a V2 and have a Kconfig
e.g CONFIG_MEASURE_DTB, which would control stripping the property -- or we
could save- > strip -> measure -> re-inject (which is a horrible idea but
that's the current reality).
> > >
> > > 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 hurt the measurements though. The current situation is a bit
weird. Ideally the firmware would provide the DTB and I would be be able
to measure prior to any fixups. However that's not the reality today. So
we do have to measure just before we install the config table. Which means
that all entries that can change across reboots needs to be ignored.
>
> 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.
Yea but measuring is a reality (and a spec for all it matters). So we need
to find some way of fixing this.
Regards
/Ilias
next prev parent reply other threads:[~2021-12-16 15:56 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 [this message]
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=Ybthk3wl3EM/wlwj@hades \
--to=ilias.apalodimas@linaro.org \
--cc=agraf@csgraf.de \
--cc=ardb@kernel.org \
--cc=mark.kettenis@xs4all.nl \
--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