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