Re: [RFC PATCH 0/7] efi/libstub: measurement initrd data loaded by the EFI stub

From: Matthew Garrett <mjg59@google.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi <linux-efi@vger.kernel.org>,
	Peter Jones <pjones@redhat.com>,
	Leif Lindholm <leif@nuviainc.com>,
	Arvind Sankar <nivedita@alum.mit.edu>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>
Subject: Re: [RFC PATCH 0/7] efi/libstub: measurement initrd data loaded by the EFI stub
Date: Mon, 2 Nov 2020 11:39:19 -0800	[thread overview]
Message-ID: <CACdnJuvC3EjQb5ZfOBynNzMPOwUm3w5CnXDCYGd10w_AW+_efw@mail.gmail.com> (raw)
In-Reply-To: <20201102170634.20575-1-ardb@kernel.org>

On Mon, Nov 2, 2020 at 9:06 AM Ard Biesheuvel <ardb@kernel.org> wrote:

> This is posted as an RFC since it is mostly an invitation to discuss how
> we can fit this into a longer term strategy for arch-agnostic secure and
> measured boot that does not hinge on the Shim+GRUB tandem, or on deep
> knowledge on the part of the bootloader regarding device trees, bootparams
> structs, allocation and placement policies of various artifacts etc etc

My initial concern was that we'd potentially do double measurement if
a separate bootloader loaded the initrd and then called the EFI entry
point, but it looks like you'll only measure if the stub loaded the
initrd itself, in which case this seems fine.

> Open questions:
> - Should we do this?

I think so. The initramfs is clearly part of our initial TCB.

> - Are Linux systems in the field using PCR value prediction when updating the
>   initrd? Does this approach interfere with that?

I'm not aware of any distro that's tried to solve this problem. I do
have an idea for how to (basically, build a generic initramfs and then
allow the bootloader to override specific configuration files - grub
has support for reading files and creating an additional cpio on the
fly), but handwave.

> - Which PCR and event type to use

Grub is measuring the initramfs (and all binaries) into PCR 9 with EV_IPL.

> - Is a separator event needed here, given that the initrd measurement is
>   recorded even if no initrd was loaded by the stub?

I think probably, but we should probably have a longer discussion
around when we should be logging separators (grub doesn't generate any
at the moment, and I don't think shim does either, and that's
definitely suboptimal for the PCR 7 case). We should probably look at
what Windows is doing here.