Message-ID: <874j6e482p.fsf@email.froward.int.ebiederm.org>
Date: Tue, 17 Sep 2024 10:24:14 -0500
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: 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
Subject: Re: [RFC] efi/tpm: add efi.tpm_log as a reserved region in
 820_table_firmware

Ard Biesheuvel <ardb@...nel.org> writes:

> Hi Eric,
>
> Thanks for chiming in.

It just looked like after James gave some expert input the
conversation got stuck, so I am just trying to move it along.

I don't think anyone knows what this whole elephant looks like,
which makes solving the problem tricky.

> On Mon, 16 Sept 2024 at 22:21, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>>
>> James Bottomley <James.Bottomley@...senPartnership.com> writes:
>>
>> > On Fri, 2024-09-13 at 04:57 -0700, Breno Leitao wrote:
>> >> Hello James,
>> >>
>> >> On Thu, Sep 12, 2024 at 12:22:01PM -0400, James Bottomley wrote:
>> >> > On Thu, 2024-09-12 at 06:03 -0700, Breno Leitao wrote:
>> >> > > Hello Ard,
>> >> > >
>> >> > > On Thu, Sep 12, 2024 at 12:51:57PM +0200, Ard Biesheuvel wrote:
>> >> > > > I don't see how this could be an EFI bug, given that it does
>> >> > > > not deal with E820 tables at all.
>> >> > >
>> >> > > I want to back up a little bit and make sure I am following the
>> >> > > discussion.
>> >> > >
>> >> > > From what I understand from previous discussion, we have an EFI
>> >> > > bug as the root cause of this issue.
>> >> > >
>> >> > > This happens because the EFI does NOT mark the EFI TPM event log
>> >> > > memory region as reserved (EFI_RESERVED_TYPE). Not having an
>> >> > > entry for the event table memory in EFI memory mapped, then
>> >> > > libstub will ignore it completely (the TPM event log memory
>> >> > > range) and not populate e820 table with it.
>> >> >
>> >> > Wait, that's not correct.  The TPM log is in memory that doesn't
>> >> > survive ExitBootServices (by design in case the OS doesn't care
>> >> > about it).  So the EFI stub actually copies it over to a new
>> >> > configuration table that is in reserved memory before it calls
>> >> > ExitBootServices.  This new copy should be in kernel reserved
>> >> > memory regardless of its e820 map status.
>> >>
>> >> First of all, thanks for clarifying some points here.
>> >>
>> >> How should the TPM log table be passed to the next kernel when
>> >> kexecing() since it didn't surive ExitBootServices?
>> >
>> > I've no idea.  I'm assuming you don't elaborately reconstruct the EFI
>> > boot services, so you can't enter the EFI boot stub before
>> > ExitBootServices is called?  So I'd guess you want to preserve the EFI
>> > table that copied the TPM data in to kernel memory.
>>
>> This leaves two practical questions if I have been following everything
>> correctly.
>>
>> 1) How to get kexec to avoid picking that memory for the new kernel to
>>    run in before it initializes itself. (AKA the getting stomped by
>>    relocate kernel problem).
>>
>> 2) How to point the new kernel to preserved tpm_log.
>>
>>
>> This recommendation is from memory so it may be a bit off but
>> the general structure should work.  The idea is as follows.
>>
>> - Pass the information between kernels.
>>
>>   It is probably simplest for the kernel to have a command line option
>>   that tells the kernel the address and size of the tpm_log.
>>
>>   We have a couple of mechanisms here.  Assuming you are loading a
>>   bzImage with kexec_file_load you should be able to have the in kernel
>>   loader to add those arguments to the kernel command line.
>>
>
> This shouldn't be necessary, and I think it is actively harmful to
> keep inventing special ways for the kexec kernel to learn about these
> things that deviate from the methods used by the first kernel. This is
> how we ended up with 5 sources of truth for the physical memory map
> (EFI memory map, memblock and 3 different versions of the e820 memory
> map).
>
> We should try very hard to make kexec idempotent, and reuse the
> existing methods where possible. In this case, the EFI configuration
> table is already being exposed to the kexec kernel, which describes
> the base of the allocation. The size of the allocation can be derived
> from the table header.
>
>> - Ensure that when the loader is finding an address to load the new
>>   kernel it treats the address of the tpm_log as unavailable.
>>
>
> The TPM log is a table created by the EFI stub loader, which is part
> of the kernel. So if we need to tweak this for kexec's benefit, I'd
> prefer changing it in a way that can accommodate the first kernel too.
> However, I think the current method already has that property so I
> don't think we need to do anything (modulo fixing the bug)

I am fine with not inventing a new mechanism, but I think we need
to reuse whatever mechanism the stub loader uses to pass it's
table to the kernel.  Not the EFI table that disappears at
ExitBootServices().

> That said, I am doubtful that the kexec kernel can make meaningful use
> of the TPM log to begin with, given that the TPM will be out of sync
> at this point. But it is still better to keep it for symmetry, letting
> the higher level kexec/kdump logic running in user space reason about
> whether the TPM log has any value to it.

Someone seems to think so or there would not be a complaint that it is
getting corrupted.

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.

Eric

Powered by blists - more mailing lists