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 17:56:51 +0100 (CET) [thread overview]
Message-ID: <d3cb57807472ff9e@bloch.sibelius.xs4all.nl> (raw)
In-Reply-To: <CAMj1kXGRx7u29EJ6CDsuOYSAhStApxetdOb7GCrTL-9GxgEYdA@mail.gmail.com> (message from Ard Biesheuvel on Thu, 16 Dec 2021 15:54:55 +0100)
> From: Ard Biesheuvel <ardb@kernel.org>
> Date: Thu, 16 Dec 2021 15:54:55 +0100
Hi Ard, Ilias,
> On Thu, 16 Dec 2021 at 15:52, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > 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.
> >
> > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>
> Acked-by: Ard Biesheuvel <ardb@kernel.org>
>
> Note that the EFI stub itself does not consume the DTB /chosen entry
> for its own randomness needs (i.e., the randomization of the physical
> placement of the kernel, which also affects low order virtual
> placement [bits 16-20]), and will blindly overwrite the seed with
> whatever the EFI_RNG_PROTOCOL returns.
But it will only do that if EFI_RNG_PROTOCOL is implemented and
sucessfully returns some random data. Otherwise "kaslr-seed" will
survive as-is. At least that is how I read the code in
drivers/firmware/efi/libstub/fdt.c:update_fdt().
And this is good. On Apple M1 systems, the Apple bootloader actually
provides a block of entropy the the kernel in their version of the
device tree. The m1n1 bootloader uses this entropy to populate the
kaslr-seed property in the device tree it passes on. And U-Boot is
used to provide an EFI implementation such that we can boot a wide
variety of OSes. At this point we don't know yet whether the SoC
includes an RNG that we can use to implement EFI_RNG_PROTOCOL in
U-Boot.
So the effect of tis change is that a Linux kernel on this platform
will run without KASLR. That doesn't seem acceptable to me.
> > ---
> > cmd/bootefi.c | 2 ++
> > include/efi_loader.h | 2 ++
> > lib/efi_loader/efi_dt_fixup.c | 22 ++++++++++++++++++++++
> > 3 files changed, 26 insertions(+)
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index d77d3b6e943d..25f9bfce9b84 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_purge_kaslr_seed(fdt);
> > +
> > /* Install device tree as UEFI table */
> > ret = efi_install_configuration_table(&efi_guid_fdt, fdt);
> > if (ret != EFI_SUCCESS) {
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 9dd6c2033634..e560401ac54f 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -519,6 +519,8 @@ efi_status_t EFIAPI efi_convert_pointer(efi_uintn_t debug_disposition,
> > void **address);
> > /* Carve out DT reserved memory ranges */
> > void efi_carve_out_dt_rsv(void *fdt);
> > +/* Purge unused kaslr-seed */
> > +void efi_purge_kaslr_seed(void *fdt);
> > /* Called by bootefi to make console interface available */
> > efi_status_t efi_console_register(void);
> > /* Called by bootefi to make all disk storage accessible as EFI objects */
> > diff --git a/lib/efi_loader/efi_dt_fixup.c b/lib/efi_loader/efi_dt_fixup.c
> > index b6fe5d2e5a34..02f7de73872e 100644
> > --- a/lib/efi_loader/efi_dt_fixup.c
> > +++ b/lib/efi_loader/efi_dt_fixup.c
> > @@ -40,6 +40,28 @@ static void efi_reserve_memory(u64 addr, u64 size, bool nomap)
> > addr, size);
> > }
> >
> > +/**
> > + * efi_remove_kaslr_seed() - Removed unused kaslr-seed
> > + *
> > + * Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for randomization
> > + * and completely ignores the kaslr-seed. Weed it out from the DTB we
> > + * hand over, which would mess up our DTB TPM measurements as well.
> > + *
> > + * @fdt: Pointer to device tree
> > + */
> > +void efi_purge_kaslr_seed(void *fdt)
> > +{
> > + int nodeoff = fdt_path_offset(fdt, "/chosen");
> > + int err = 0;
> > +
> > + if (nodeoff < 0)
> > + return;
> > +
> > + err = fdt_delprop(fdt, nodeoff, "kaslr-seed");
> > + if (err < 0)
> > + log_err("Error deleting kaslr-seed\n");
> > +}
> > +
> > /**
> > * efi_carve_out_dt_rsv() - Carve out DT reserved memory ranges
> > *
> > --
> > 2.30.2
> >
>
next prev parent reply other threads:[~2021-12-16 16:57 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 [this message]
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
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=d3cb57807472ff9e@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