Re: [RFC] efi/tpm: add efi.tpm_log as a reserved region in 820_table_firmware

Re: [RFC] efi/tpm: add efi.tpm_log as a reserved region in 820_table_firmware

[Jonathan McDowell]

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@xmission.com> wrote:
> > Ard Biesheuvel <ardb@kernel.org> writes:
> > > On Tue, 17 Sept 2024 at 17:24, Eric W. Biederman <ebiederm@xmission.com> wrote:
> > >> Ard Biesheuvel <ardb@kernel.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

Re: [RFC] efi/tpm: add efi.tpm_log as a reserved region in 820_table_firmware

[Breno Leitao]

On Wed, Oct 09, 2024 at 10:10:57AM +0100, Jonathan McDowell wrote:
> 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@xmission.com> wrote:
> > > Ard Biesheuvel <ardb@kernel.org> writes:
> > > > On Tue, 17 Sept 2024 at 17:24, Eric W. Biederman <ebiederm@xmission.com> wrote:
> > > >> Ard Biesheuvel <ardb@kernel.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).

What about in the case where you don't have Grub, but, use the kernel as
the bootloader, kexecing into the desired kernel?

Will the bootloader-kernel touch the same PCRs as GRUB, or it will only
touch PCRs above 10?

Thanks
--breno

Re: [RFC] efi/tpm: add efi.tpm_log as a reserved region in 820_table_firmware

[Jonathan McDowell]

On Wed, Oct 09, 2024 at 03:46:32AM -0700, Breno Leitao wrote:
> On Wed, Oct 09, 2024 at 10:10:57AM +0100, Jonathan McDowell wrote:
> > 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@xmission.com> wrote:
> > > > Ard Biesheuvel <ardb@kernel.org> writes:
> > > > > On Tue, 17 Sept 2024 at 17:24, Eric W. Biederman <ebiederm@xmission.com> wrote:
> > > > >> Ard Biesheuvel <ardb@kernel.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).
> 
> What about in the case where you don't have Grub, but, use the kernel as
> the bootloader, kexecing into the desired kernel?
> 
> Will the bootloader-kernel touch the same PCRs as GRUB, or it will only
> touch PCRs above 10?

A kernel kexecing into another will generally use IMA if it wants to
measure into the TPM, which will use PCR 10 by default and not conflict
with the firmware PCRs (and you then use the IMA integrity log, which is
passed over a kexec, to work out the kexec side of things).

You still need the firmware event log in that case because the
"bootloader" kernel combo you load is measured into the TPM by the
firmware.

You _could_ technically configure things up to re-use some of the
firmware PCRs, but it generally wouldn't make a lot of sense to do so
and I've not seen any examples of that sort of configuration.

J.

-- 
101 things you can't have too much of : 41 - Tea.