[PATCH v2 7/7] ima: record log size at kexec load and execute
Tushar Sugandhi
tusharsu at linux.microsoft.com
Fri Oct 20 13:40:53 PDT 2023
On 10/12/23 17:27, Stefan Berger wrote:
>
> On 10/5/23 14:26, Tushar Sugandhi wrote:
>> The window between kexec 'load' and 'execute' could be arbitrarily long.
>> Even with the large chunk of memory allocated at kexec 'load', it may
>> run out which would result in missing events in IMA log after the system
>> soft reboots to the new Kernel. This would result in IMA measurements
>> getting out of sync with the TPM PCR quotes which would result in remote
>> attestation failing for that system. There is currently no way for the
>> new Kernel to know if the IMA log TPM PCR quote out of sync problem is
>> because of the missing measurements during kexec.
>>
>> Define two new IMA events, 'kexec_load' and 'kexec_execute', to be
>> measured at kexec 'load' and 'execute' respectively.
>>
>> IMA measures 'boot_aggregate' as the first event when the system boots -
>> either cold boot or kexec soft boot. In case when the system goes
>> through multiple soft reboots, the number of 'boot_aggregate' events in
>> IMA log corresponds to total number of boots (cold boot plus multiple
>> kexec soft reboots). With this change, there would be additional
>> 'kexec_load' and 'kexec_execute' events in between the two
>> 'boot_aggregate' events. In rare cases, when the system runs out of
>> memory during kexec soft reboot, 'kexec_execute' won't be copied since
>> its one of the very last event measured just before kexec soft reboot.
>> The absence of the event 'kexec_execute' in between the two
>> boot_aggregate' events would signal the attestation service that the IMA
>> log on the system is out of sync with TPM PCR quotes and the system needs
>> to be cold booted for the remote attestation to succeed again.
>>
>>
>> @@ -198,6 +208,7 @@ void ima_add_kexec_buffer(struct kimage *image)
>> static int ima_update_kexec_buffer(struct notifier_block *self,
>> unsigned long action, void *data)
>> {
>> + char ima_kexec_event[IMA_KEXEC_EVENT_LEN];
>> void *buf = NULL;
>> size_t buf_size;
>> bool resume = false;
>> @@ -213,9 +224,31 @@ static int ima_update_kexec_buffer(struct
>> notifier_block *self,
>> return NOTIFY_OK;
>> }
>> + buf_size = ima_get_binary_runtime_size();
>> + scnprintf(ima_kexec_event, IMA_KEXEC_EVENT_LEN,
>> + "kexec_segment_size=%lu;ima_binary_runtime_size=%lu;",
>> + kexec_segment_size, buf_size);
>> +
>> + /*
>> + * This is one of the very last events measured by IMA before kexec
>> + * soft rebooting into the new Kernal.
>> + * This event can be used as a marker after the system soft reboots
>> + * to the new Kernel to check if there was sufficient memory
>> allocated
>> + * at kexec 'load' to capture the events measured between the window
>> + * of kexec 'load' and 'execute'.
>> + * This event needs to be present in the IMA log, in between the two
>> + * 'boot_aggregate' events that are logged for the previous boot and
>> + * the current soft reboot. If it is not present after the system
>> soft
>> + * reboots into the new Kernel, it would mean the IMA log is not
>> + * consistent with the TPM PCR quotes, and the system needs to be
>> + * cold-booted for the attestation to succeed again.
>> + */
>> + ima_measure_critical_data("ima_kexec", "kexec_execute",
>> + ima_kexec_event, strlen(ima_kexec_event),
>> + false, NULL, 0);
>> +
>> ima_measurements_suspend();
>> - buf_size = ima_get_binary_runtime_size();
>
> This should be removed earlier, in 2/7.
>
>
>
Agreed. Will do.
~Tushar
>> ret = ima_dump_measurement_list(&buf_size, &buf,
>> kexec_segment_size);
More information about the kexec
mailing list