Ard Biesheuvel <ardb@xxxxxxxxxx> writes: > On Tue, 17 Sept 2024 at 17:24, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: >> >> 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: >> >> > ... >> >> >> >> 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(). >> > > Not sure what you mean here - the EFI table that gets clobbered by > kexec *is* the table that is created by the stub loader to pass the > TPM log to the kernel. Not sure what alternative you have in mind > here. I was referring to whatever the EFI table that James Bottomley mentioned that I presume the stub loader reads from when the stub loader constructs the tpm_log that is passed to the kernel. So I believe we are in agreement of everything except terminology. >> > 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. >> > > No. The problem is that the size of the table is *in* the table, and > so if it gets corrupted, the code that attempts to memblock_reserve() > it goes off into the weeds. But that does not imply there is a point > to having access to this table from a kexec kernel in the first place. If there is no point to having access to it then we should just not pass anything to the loaded kernel, so the kernel does not think there is anything there. >> 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. If someone wants the tpm_log then we need to solve this problem. Eric _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
