From: Stefan Berger <stefanb@linux.ibm.com>
To: Mimi Zohar <zohar@linux.ibm.com>,
linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, roberto.sassu@huawei.com,
Tushar Sugandhi <tusharsu@linux.microsoft.com>
Subject: Re: [PATCH v2] ima: Suspend PCR extends and log appends when rebooting
Date: Wed, 13 Nov 2024 07:33:06 -0500 [thread overview]
Message-ID: <7e66377e-38d6-4885-acb6-e9a72573a697@linux.ibm.com> (raw)
In-Reply-To: <e72ec14c-1593-410f-a4ed-a5583b36fc7c@linux.ibm.com>
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@linux.microsoft.com>
>>> Signed-off-by: Stefan Berger <stefanb@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.
prev parent reply other threads:[~2024-11-13 12:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-12 16:52 [PATCH v2] ima: Suspend PCR extends and log appends when rebooting Stefan Berger
2024-11-12 17:59 ` Jarkko Sakkinen
2024-11-12 23:42 ` Mimi Zohar
2024-11-13 2:28 ` Stefan Berger
2024-11-13 12:33 ` Stefan Berger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7e66377e-38d6-4885-acb6-e9a72573a697@linux.ibm.com \
--to=stefanb@linux.ibm.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=roberto.sassu@huawei.com \
--cc=tusharsu@linux.microsoft.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).