[PATCH v2] ima: Suspend PCR extends and log appends when rebooting

Stefan Berger stefanb at linux.ibm.com
Wed Nov 13 12:33:06 UTC 2024



On 11/12/24 9:28 PM, Stefan Berger wrote:
> 
> 
> On 11/12/24 6:42 PM, Mimi Zohar wrote:
>> On Tue, 2024-11-12 at 11:52 -0500, Stefan Berger wrote:
>>> To avoid the following types of error messages due to a failure by 
>>> the TPM
>>> driver to use the TPM, suspend TPM PCR extensions and the appending of
>>> entries to the IMA log once IMA's reboot notifier has been called. This
>>> avoids trying to use the TPM after the TPM subsystem has been shut down.
>>>
>>> [111707.685315][    T1] ima: Error Communicating to TPM chip, result: 
>>> -19
>>> [111707.685960][    T1] ima: Error Communicating to TPM chip, result: 
>>> -19
>>>
>>> This error could be observed on a ppc64 machine running SuSE Linux where
>>> processes are still accessing files after devices have been shut down.
>>>
>>> Suspending the IMA log and PCR extensions shortly before reboot does not
>>> seem to open a significant measurement gap since neither TPM quoting 
>>> would
>>> work for attestation nor that new log entries could be written to 
>>> anywhere
>>> after devices have been shut down. However, there's a time window 
>>> between
>>> the invocation of the reboot notifier and the shutdown of devices in
>>> kernel_restart_prepare() where __usermodehelper_disable() waits for all
>>> running_helpers to exit. During this time window IMA could now miss log
>>> entries even though attestation would still work. The reboot of the 
>>> system
>>> shortly after may make this small gap insignificant.
>>>
>>> Signed-off-by: Tushar Sugandhi <tusharsu at linux.microsoft.com>
>>> Signed-off-by: Stefan Berger <stefanb at linux.ibm.com>
>>
>> Thanks, Stefan.  The patch looks good.  Based on the updated patch 
>> description,
>> I'm wondering if we should be testing the "system_state" instead of 
>> registering
>> a reboot notifier?
> 
> That's a possibility and would definitely be less code. I don't see why 
> not...
> 
... the missing synchronization with the mutex speaks against it. If we 
don't have it we could try to use the TPM subsystem after it's been shut 
down.



More information about the Linux-security-module-archive mailing list