On Tue, Apr 26, 2022 at 09:49:53AM -0400, Mimi Zohar wrote: > On Tue, 2022-04-26 at 12:08 +0000, Jonathan McDowell wrote: > > On Mon, Apr 25, 2022 at 12:29:17PM -0400, Mimi Zohar wrote: > > > Hi Jonathan, > > > > > > On Fri, 2022-04-22 at 13:50 +0000, Jonathan McDowell wrote: > > > > On kexec file load Integrity Measurement Architecture (IMA) subsystem > > > > may verify the IMA signature of the kernel and initramfs, and measure > > > > it. The command line parameters passed to the kernel in the kexec call > > > > may also be measured by IMA. A remote attestation service can verify > > > > a TPM quote based on the TPM event log, the IMA measurement list, and > > > > the TPM PCR data. This can be achieved only if the IMA measurement log > > > > is carried over from the current kernel to the next kernel across > > > > the kexec call. > > > > > > > > powerpc and ARM64 both achieve this using device tree with a > > > > "linux,ima-kexec-buffer" node. x86 platforms generally don't make use of > > > > device tree, so the IMA infrastructure is extended to allow non device > > > > tree platforms to provide a log buffer. x86 then passes the IMA buffer > > > > to the new kernel via the setup_data mechanism. > > > > > > > > Signed-off-by: Jonathan McDowell <noodles@xxxxxx> > > > > > > FYI, after applying, building, and booting a kernel with this patch, > > > "kexec -s -l /boot/vmlinuz-5.18.0-rc4+ --reuse-cmdline -- > > > initrd=/boot/initramfs-5.18.0-rc4+.img" properly loads the kernel, but > > > "kexec -s -e" fails to reboot, at least on a test laptop even with only > > > the "boot_aggregate" measurement record. > > > > > > Without enabling CONFIG_IMA_KEXEC, kexec boots properly. > > > > Thanks for giving it a try. At a guess your laptop is booting with > > EFI, whereas for my testing I was using qemu with legacy BIOS. I've > > managed to reproduce the issue with qemu+OVMF and isolated the mistake > > in the setup data calculation I made when EFI is involved. If you have > > time can you try with the below on top of the original patch? > > Thank you! With the change, as expected there are two "boot_aggregate" > records in the measurement list. With a custom policy, the measurement > list verifies. Excellent, thanks for verifying. I'll get the fixed v2 out. ... > FYI, the builtin "ima_policy=tcb" results in measurement violations. > Normally, the measurement list can still be verified using the evmctl > "--ignore-violations" option. For some reason with the "tcb" policy, > the measurement list doesn't verify even with the "--ignore-violations" > option after kexec. I assume this is a result of additional > measurements being added after the kexec load, which aren't being > carried across kexec. I believe with "tcb" things like the subsequent exec of kexec to actually do the reboot will end up measured, and as the kexec buffer is static it won't include that. Also there's an issue about the fact that we measure the kexec pieces even if we don't actually do the kexec; there's no marker that confirms the kexec took place. It's separate to this patch (in that it affects the device tree kexec infrastructure too) but it's conceivable that an attacker could measure in the new kernel details and not actually do the kexec, and that's not distinguishable from the kexec happening. One approach might be to add a marker in the kexec ima buffer such that if it's not present we know the kexec hasn't happened, but I need to think through that a bit more. J.
