From: Mimi Zohar <zohar@linux.ibm.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
linux-integrity@vger.kernel.org
Cc: eric.snowberg@oracle.com, dhowells@redhat.com,
mathew.j.martineau@linux.intel.com, matthewgarrett@google.com,
sashal@kernel.org, jamorris@linux.microsoft.com,
linux-kernel@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [PATCH v4 2/2] IMA: Call workqueue functions to measure queued keys
Date: Mon, 16 Dec 2019 13:05:15 +0000 [thread overview]
Message-ID: <1576501515.4579.332.camel@linux.ibm.com> (raw)
In-Reply-To: <1576479187.3784.1.camel@HansenPartnership.com>
On Mon, 2019-12-16 at 15:53 +0900, James Bottomley wrote:
> That doesn't matter ... the question is, is the input assumption that
> both pre/post have to be called or neither must correct? If so, the
> code is wrong, if not, explain why.
Thanks, James, for looking at the locking.
"ima_process_keys" is set once. Once it is set, the keys are measured
immediately. For performance to avoid taking the mutex, both the
reader and writer check "ima_process_keys" twice, once without taking
the lock and, again, after taking the lock. Based on the second test,
the reader queues the "key" or not. Refer to ima_queue_key().
The latest patch version sets "ima_process_keys" after taking the
lock. With this change, the comment in ima_process_queued_keys() is
now correct. We're now guaranteed to process the queued "keys" just
once and not drop any "key" measurements.
I hope this answers your question.
Mimi
WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
linux-integrity@vger.kernel.org
Cc: eric.snowberg@oracle.com, dhowells@redhat.com,
mathew.j.martineau@linux.intel.com, matthewgarrett@google.com,
sashal@kernel.org, jamorris@linux.microsoft.com,
linux-kernel@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [PATCH v4 2/2] IMA: Call workqueue functions to measure queued keys
Date: Mon, 16 Dec 2019 08:05:15 -0500 [thread overview]
Message-ID: <1576501515.4579.332.camel@linux.ibm.com> (raw)
In-Reply-To: <1576479187.3784.1.camel@HansenPartnership.com>
On Mon, 2019-12-16 at 15:53 +0900, James Bottomley wrote:
> That doesn't matter ... the question is, is the input assumption that
> both pre/post have to be called or neither must correct? If so, the
> code is wrong, if not, explain why.
Thanks, James, for looking at the locking.
"ima_process_keys" is set once. Once it is set, the keys are measured
immediately. For performance to avoid taking the mutex, both the
reader and writer check "ima_process_keys" twice, once without taking
the lock and, again, after taking the lock. Based on the second test,
the reader queues the "key" or not. Refer to ima_queue_key().
The latest patch version sets "ima_process_keys" after taking the
lock. With this change, the comment in ima_process_queued_keys() is
now correct. We're now guaranteed to process the queued "keys" just
once and not drop any "key" measurements.
I hope this answers your question.
Mimi
next prev parent reply other threads:[~2019-12-16 13:05 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-13 17:18 [PATCH v4 0/2] IMA: Deferred measurement of keys Lakshmi Ramasubramanian
2019-12-13 17:18 ` Lakshmi Ramasubramanian
2019-12-13 17:18 ` [PATCH v4 1/2] IMA: Define workqueue for early boot "key" measurements Lakshmi Ramasubramanian
2019-12-13 17:18 ` Lakshmi Ramasubramanian
2019-12-16 12:30 ` Mimi Zohar
2019-12-16 12:30 ` Mimi Zohar
2019-12-16 23:44 ` Lakshmi Ramasubramanian
2019-12-16 23:44 ` Lakshmi Ramasubramanian
2019-12-17 10:54 ` Mimi Zohar
2019-12-17 10:54 ` Mimi Zohar
2019-12-13 17:18 ` [PATCH v4 2/2] IMA: Call workqueue functions to measure queued keys Lakshmi Ramasubramanian
2019-12-13 17:18 ` Lakshmi Ramasubramanian
2019-12-13 17:25 ` James Bottomley
2019-12-13 17:25 ` James Bottomley
2019-12-13 17:31 ` Lakshmi Ramasubramanian
2019-12-13 17:31 ` Lakshmi Ramasubramanian
2019-12-15 15:22 ` James Bottomley
2019-12-15 15:22 ` James Bottomley
2019-12-16 1:12 ` Lakshmi Ramasubramanian
2019-12-16 1:12 ` Lakshmi Ramasubramanian
2019-12-16 6:53 ` James Bottomley
2019-12-16 6:53 ` James Bottomley
2019-12-16 13:05 ` Mimi Zohar [this message]
2019-12-16 13:05 ` Mimi Zohar
2019-12-16 19:20 ` Lakshmi Ramasubramanian
2019-12-16 19:20 ` Lakshmi Ramasubramanian
2019-12-16 21:17 ` James Bottomley
2019-12-16 21:17 ` James Bottomley
2019-12-16 21:37 ` Lakshmi Ramasubramanian
2019-12-16 21:37 ` Lakshmi Ramasubramanian
2019-12-16 21:52 ` Lakshmi Ramasubramanian
2019-12-16 21:52 ` Lakshmi Ramasubramanian
2019-12-17 22:22 ` Lakshmi Ramasubramanian
2019-12-17 22:22 ` Lakshmi Ramasubramanian
2019-12-18 2:01 ` James Bottomley
2019-12-18 2:01 ` James Bottomley
2019-12-18 2:44 ` Lakshmi Ramasubramanian
2019-12-18 2:44 ` Lakshmi Ramasubramanian
2019-12-18 2:59 ` Lakshmi Ramasubramanian
2019-12-18 3:00 ` Lakshmi Ramasubramanian
2019-12-18 3:24 ` James Bottomley
2019-12-18 3:24 ` James Bottomley
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=1576501515.4579.332.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=dhowells@redhat.com \
--cc=eric.snowberg@oracle.com \
--cc=jamorris@linux.microsoft.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathew.j.martineau@linux.intel.com \
--cc=matthewgarrett@google.com \
--cc=nramas@linux.microsoft.com \
--cc=sashal@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.