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@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? 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.
