On Fri, Jun 03, 2022 at 11:16:04PM -0700, Tushar Sugandhi wrote: > We believe we have found one gap in the IMA/kexec interaction. > And we need your inputs as Linux Kernel maintainers/experts to fix that > gap. > > ------------- > Problem: > ------------- > The current Kernel behavior is IMA measurements are snapshotted at > 'kexec load' and not at 'kexec execute'. And IMA log is then carried > over to the new Kernel after 'kexec execute'. > > Some systems can be configured to call 'kexec load' first, and followed > by 'kexec execute' after some time. (as opposed to calling 'load' and > 'execute' in one single kexec command). In this scenario, if new IMA > measurements are added between 'kexec load' and 'kexec execute' - the > TPM PCRs are extended with the IMA events between load and execute, but > those IMA events are not carried over to the new kernel after kexec soft > reboot. This results in mismatch between TPM PCR quotes and the actual > IMA measurements log post kexec. > > =========================================================================== > ------------- > Scenario > ------------- > Here is the order of operations I followed to confirm the issue. > > (a) Call 'kexec load' > > #kexec -s -l /etc/ima/Image.kexec --reuse-cmdline > > > (b) Touch one of the files that would be measured by IMA > > #cat /run/systemd/journal/streams/8:16351 > > > (c) Verify that this measurement event is part of the IMA log. > > #cat /sys/kernel/security/ima/ascii_runtime_measurements | grep 16351 > > <returns the file entry in IMA log> > > (d) Call 'kexec execute' > > #kexec -s -e > > > (e) After kexec soft reboot, the file measurement event is not present > in the IMA log anymore. Because this measurement in the previous > kernel had happened after the IMA log was snapshotted in the > previous kernel. > > #cat /sys/kernel/security/ima/ascii_runtime_measurements | grep 16351 > > <does not return the file entry in IMA log> > > =========================================================================== > ------------- > Solution > ------------- > Tyler pointed me to the past work in this area. > (Please see references section below) > > I used it to create the patches for capturing IMA events in between > "kexec load" and "kexec execute". (please find attached) > > - 0001-kexec_file-Add-mechanism-to-update-kexec-segments.patch > - 0002-ima-update-kexec-buffer-before-executing-soft-reboot.patch > - 0003-ima-on-soft-reboot-save-the-measurement-list.patch > > My patches are based on [1] and [2] in the References section below. > I also looked at [3]. It has a few kexec_*_handover_buffer(). > I was not sure if they were needed. As per my limited understanding in > kexec space [1] and [2] together seemed sufficient for the solution. > =========================================================================== > ------------------------------------------ > Problems in the solution above > ------------------------------------------ > Earlier my solution patches were crashing the Kernel. After a few fixes, > the patches are not crashing the Kernel anymore, but they don't seem to be > working to capture the events between 'kexec load' and 'kexec execute' > either. > > When I was debugging it using printks and gdb, I found one potential > location where it was failing. > > test_0001-move-ima_add_kexec_buffer-from-kexec-load-to-execute.patch > has that location. > > > I would really appreciate if someone of you could help me provide > further guidance to make progress on this work. The main piece that seems to be missing is updating the size of the IMA buffer in the mechanism used to pass its details to the new kernel (so device tree in current mainline [setup_ima_buffer], the setup_data piece in my x86_64 patches). Without that you'll only load the original set of measurements even if the extra data is in the buffer. I think there's also a potential problem in that you assume an extra page is sufficient for any additional measurements which may or may not be the case - I don't see any check in ima_update_kexec_buffer that the buffer is big enough for the new IMA data. J. _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
