All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
	ardb@kernel.org, agraf@csgraf.de, u-boot@lists.denx.de
Subject: Re: [PATCH v2] efi_loader: Get rid of kaslr-seed
Date: Mon, 3 Jan 2022 09:30:05 +0200	[thread overview]
Message-ID: <YdKl/atZDWHcp4Zz@hades> (raw)
In-Reply-To: <d3cb823d8fb9989d@bloch.sibelius.xs4all.nl>

Hi Mark, 

On Sun, Jan 02, 2022 at 10:27:50PM +0100, Mark Kettenis wrote:
> > Date: Sun, 02 Jan 2022 22:06:11 +0100
> > From: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > 
> > Am 2. Januar 2022 21:50:35 MEZ schrieb Ilias Apalodimas <ilias.apalodimas@linaro.org>:
> > >Hi Heinrich,
> > >
> > >> > > > > 
> > >
> > >[...]
> > >
> > >> > > > > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > >> > > > > index d77d3b6e943d..57f13ce701ec 100644
> > >> > > > > --- a/cmd/bootefi.c
> > >> > > > > +++ b/cmd/bootefi.c
> > >> > > > > @@ -310,6 +310,8 @@ efi_status_t efi_install_fdt(void *fdt)
> > >> > > > >   	/* Create memory reservations as indicated by the device tree */
> > >> > > > >   	efi_carve_out_dt_rsv(fdt);
> > >> > > > > 
> > >> > > > > +	efi_try_purge_kaslr_seed(fdt);
> > >> 
> > >> This function should only be invoked for CONFIG_EFI_TCG2_PROTOCOL=y.
> > >
> > >Why?  As we discussed the kernel ignores the kaslr-seed for the
> > >physical randomization.  The only reason we would like to keep it is 
> > >for the randomization of the virtual address.  But if the EFI
> > >RNG protocol is installed the EFI stub is already doing the right thing. 
> > >So I really think purging it if EFI RNG is installed is the best option
> > >here (regardless of TPM measurements)
> > >
> > 
> > The only reason to delete kaslr-seed is that it conflicts with
> > measured boot. If an OS prefers the RNG protocol over kaslr-seed is
> > the decision of the OS and nothing U-Boot has to care about.
> 
> But it is also up to the OS to decide whether it cares about measured
> boot or not.
>  
> > You will have to delete kaslr-seed no matter if you have a RNG
> > protocol or not if and only if you want to use measured boot.
> 
> So you shouldn't just unconditionally delete kaslr-seed if the
> CONFIG_EFI_TCG2_PROTOCOL has been enabled, but only if it is actually
> used...  But is that even possible?

I can't think of any (sane) way to figure this out.

> 
> So maybe you should just specify the certain properties (such as
> kaslr-seed) should be skipped when calculating the hash of the device
> tree.
> 

We could, but I'd like to avoid that unless we don't have a better
alternative.

Thanks
/Ilias

  reply	other threads:[~2022-01-03  7:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17  7:06 [PATCH v2] efi_loader: Get rid of kaslr-seed Ilias Apalodimas
2021-12-17 10:59 ` Heinrich Schuchardt
2021-12-17 11:13   ` Ilias Apalodimas
2021-12-17 11:13 ` Mark Kettenis
2021-12-17 11:23   ` Ilias Apalodimas
2021-12-17 11:33     ` Mark Kettenis
2022-01-02 10:05       ` Heinrich Schuchardt
2022-01-02 20:50         ` Ilias Apalodimas
2022-01-02 21:06           ` Heinrich Schuchardt
2022-01-02 21:27             ` Mark Kettenis
2022-01-03  7:30               ` Ilias Apalodimas [this message]
2022-01-03  7:27             ` 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=YdKl/atZDWHcp4Zz@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.