Ard Biesheuvel <ardb@xxxxxxxxxx> 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@xxxxxxxxxxxx> wrote: >> >> James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
