Message ID | 20231005182602.634615-1-tusharsu@linux.microsoft.com (mailing list archive) |
---|---|
Headers | show |
Series | ima: kexec: measure events between kexec load and execute | expand |
On Fri, 2023-10-27 at 11:18 -0400, Mimi Zohar wrote: > On Thu, 2023-10-05 at 11:25 -0700, Tushar Sugandhi wrote: > > The current Kernel behavior is IMA measurements snapshot is taken at > > kexec 'load' and not at kexec 'execute'. 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). > > Additional measurements may be introduced by the kexec load itself. > Saving the measurement list as close as possible to the reboot is > beneficial, whether or not the kexec load and kexec execute are > executed separately. > > > In such 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 list, after the system boots into the new kexec > > image. This mismatch results in the remote attestation failing for that > > system. > > > > This patch series proposes a solution to solve this problem by allocating > > the necessary buffer at kexec 'load' time, and populating the buffer > > with the IMA measurements at kexec 'execute' time. > > How about beginning the paragraph with "To solve this problem allocate > ... and populate ..." Does this patch set take into account kexec_calculate_store_digests(), which is called from kexec_load, and verify_sha256_digest()?
On 10/27/23 08:18, Mimi Zohar wrote: > On Thu, 2023-10-05 at 11:25 -0700, Tushar Sugandhi wrote: >> The current Kernel behavior is IMA measurements snapshot is taken at >> kexec 'load' and not at kexec 'execute'. 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). > > Additional measurements may be introduced by the kexec load itself. > Saving the measurement list as close as possible to the reboot is > beneficial, whether or not the kexec load and kexec execute are > executed separately. > True. What I am trying to say here is the longer the window between 'load' and 'execute', greater are the chances of measurements getting added. But as long as a single measurement gets added between 'load' and 'execute', it will break the attestation after kexec soft-reboot. So maybe the above line in the patch description is not necessary. I will remove. >> In such 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 list, after the system boots into the new kexec >> image. This mismatch results in the remote attestation failing for that >> system. >> >> This patch series proposes a solution to solve this problem by allocating >> the necessary buffer at kexec 'load' time, and populating the buffer >> with the IMA measurements at kexec 'execute' time. > > How about beginning the paragraph with "To solve this problem allocate > ... and populate ..." > Sure. Will do. ~Tushar
On 10/27/23 12:51, Mimi Zohar wrote: > Does this patch set take into account kexec_calculate_store_digests(), > which is called from kexec_load, and verify_sha256_digest()? I am not yet sure if my patches will impact the kexec_calculate_store_digests() and verify_sha256_digest() functionality. I will investigate further and get back to you as soon as possible. Thanks for bringing this up Mimi. ~Tushar