Message-ID: <ZwZIoQobJrltBpTX@earth.li>
Date: Wed, 9 Oct 2024 10:10:57 +0100
From: Jonathan McDowell <noodles@...th.li>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Breno Leitao <leitao@...ian.org>,
	Usama Arif <usamaarif642@...il.com>, linux-efi@...r.kernel.org,
	kexec@...ts.infradead.org, bhe@...hat.com, vgoyal@...hat.com,
	tglx@...utronix.de, dave.hansen@...ux.intel.com, x86@...nel.org,
	linux-kernel@...r.kernel.org, rmikey@...a.com, gourry@...rry.net,
	linux-integrity@...r.kernel.org
Subject: Re: [RFC] efi/tpm: add efi.tpm_log as a reserved region in
 820_table_firmware

On Wed, Sep 18, 2024 at 09:36:06AM +0200, Ard Biesheuvel wrote:
> On Wed, 18 Sept 2024 at 05:14, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> > Ard Biesheuvel <ardb@...nel.org> writes:
> > > On Tue, 17 Sept 2024 at 17:24, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> > >> Ard Biesheuvel <ardb@...nel.org> writes:

> > >> This should not be the kexec-on-panic kernel as that runs in memory
> > >> that is reserved solely for it's own use.  So we are talking something
> > >> like using kexec as a bootloader.
> > >
> > > kexec as a bootloader under TPM based measured boot will need to do a
> > > lot more than pass the firmware's event log to the next kernel. I'd
> > > expect a properly engineered kexec to replace this table entirely, and
> > > include the hashes of the assets it has loaded and measured into the
> > > respective PCRs.
> > >
> > > But let's stick to solving the actual issue here, rather than
> > > philosophize on how kexec might work in this context.
> >
> > I am fine with that.  The complaint I had seen was that the table was
> > being corrupted and asking how to solve that.  It seems I haven't read
> > the part of the conversation where it was made clear that no one wants
> > the tpm_log after kexec.
> >
> It was not made clear, that is why I raised the question. I argued
> that the TPM log has limited utility after a kexec, given that we will
> be in one of two situations:
> - the kexec boot chain cares about the TPM and measured boot, and will
> therefore have extended the TPM's PCRs and the TPM log will be out of
> sync;
> - the kexec boot chain does not care, and so there is no point in
> forwarding the TPM log.
> 
> Perhaps there is a third case where kdump wants to inspect the TPM log
> that the crashed kernel accessed? But this is rather speculative.

Generally the kernel/host OS and the firmware are touching different
PCRs in the TPM.

The firmware eventlog covers what the firmware/bootloader measured;
itself, option ROMs, secure boot details, bootloader, initial
kernel/initrd (if we're talking grub as the initial bootloader). These
details are not changed by a kexec, and provide the anchor of the
software trust chain.

A kexec'd kernel will generally not touch the same PCRs. The primary way
I know to carry kexec measurements / logs over to new kernels is using
IMA, which will be configured to use one of the later PCRs (default of
10).

That means that the firmware event log is still completely valid to
subsequent kernels, and is still required to validate the
firmware/bootloader trust chain. You then probably _also_ want to make
use of the IMA log to validate the kexec'd kernel chain, but that's
separate.

> > If someone wants the tpm_log then we need to solve this problem.
> Agreed.

There's a real requirement and use for kexec'd kernels to be able to
continue to access the firmware TPM event log; to the extent that there
are also patches floating around to have this carried over via device
tree on non-UEFI platforms.

J.

-- 
Avoid temporary variables and strange women.
This .sig brought to you by the letter U and the number 37
Product of the Republic of HuggieTag

Powered by blists - more mailing lists