On Wed, 2025-04-02 at 05:47 -0700, steven chen wrote: > The amount of memory allocated at kexec load, even with the extra memory > allocated, might not be large enough for the entire measurement list. The > indeterminate interval between kexec 'load' and 'execute' could exacerbate > this problem. > > Define two new IMA events, 'kexec_load' and 'kexec_execute', to be > measured as critical data at kexec 'load' and 'execute' respectively. > Report the allocated kexec segment size, IMA binary log size and the > runtime measurements count as part of those events. > > These events, and the values reported through them, serve as markers in > the IMA log to verify the IMA events are captured during kexec soft > reboot. The presence of a 'kexec_load' event in between the last two > 'boot_aggregate' events in the IMA log implies this is a kexec soft > reboot, and not a cold-boot. And the absence of 'kexec_execute' event > after kexec soft reboot implies missing events in that window which > results in inconsistency with TPM PCR quotes, necessitating a cold boot > for a successful remote attestation. > > These critical data events are displayed as hex encoded ascii in the > ascii_runtime_measurement_list. Verifying the critical data hash requires > calculating the hash of the decoded ascii string. > > For example, to verify the 'kexec_load' data hash: > > sudo cat /sys/kernel/security/integrity/ima/ascii_runtime_measurements > > grep kexec_load | cut -d' ' -f 6 | xxd -r -p | sha256sum > > > To verify the 'kexec_execute' data hash: > > sudo cat /sys/kernel/security/integrity/ima/ascii_runtime_measurements > > grep kexec_execute | cut -d' ' -f 6 | xxd -r -p | sha256sum > > Signed-off-by: Tushar Sugandhi <tusha...@linux.microsoft.com> > Signed-off-by: steven chen <chen...@linux.microsoft.com> > Reviewed-by: Stefan Berger <stef...@linux.ibm.com>
Thanks, Steven. Reviewed-by: Mimi Zohar <zo...@linux.ibm.com>
