mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	zohar@linux.ibm.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: Sun, 15 Dec 2019 17:12:02 -0800	[thread overview]
Message-ID: <1568ff14-316f-f2c4-84d4-7ca4c0a1936a@linux.microsoft.com> (raw)
In-Reply-To: <1576423353.3343.3.camel@HansenPartnership.com>

On 12/15/2019 7:22 AM, James Bottomley wrote:

Hi James,

> 
> This is the problem:
> 
> if (!flag)
>      pre()
> .
> .
> .
> if (!flag)
>      post()
> 
> And your pre and post function either have to both run or neither must.
>   However, the flag is set asynchronously, so if it gets set while
> another thread is running through the above code, it can change after
> pre is run but before post is.
> 
> James

The pre() and post() functions you have referenced above including the 
check for the flag are executed with the mutex held.

Please see Mimi's response to the v3 email. I have copied it below:

************************************
Reading the flag IS lock protected, just spread across two functions.
For performance, ima_post_key_create_or_update() checks
ima_process_keys, before calling ima_queue_key(), which takes the
mutex before checking ima_process_keys again.

As long as both the reader and writer, take the mutex before checking
the flag, the locking is fine.  The additional check, before taking
the mutex, is simply for performance.
************************************

The flag is checked with the mutex held in the "reader" - 
ima_queue_key(). The key is queued with the mutex held only if the flag 
is false.

The flag is protected in the "writer" also - ima_process_queued_keys(). 
The flag is checked with the mutex held, set to true, and queued keys 
(if any) are transferred to the temp list.

As Mimi has pointed out the additional check of the flag, before taking 
the mutex in ima_post_key_create_or_update() and in 
ima_process_queued_keys(), is for performance reason.

If the flag is true, there is no need to take the mutex to check it 
again in those functions.

thanks,
  -lakshmi

  reply	other threads:[~2019-12-16  1:11 UTC|newest]

Thread overview: 21+ 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 ` [PATCH v4 1/2] IMA: Define workqueue for early boot "key" measurements Lakshmi Ramasubramanian
2019-12-16 12:30   ` Mimi Zohar
2019-12-16 23:44     ` Lakshmi Ramasubramanian
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:25   ` James Bottomley
2019-12-13 17:31     ` Lakshmi Ramasubramanian
2019-12-15 15:22       ` James Bottomley
2019-12-16  1:12         ` Lakshmi Ramasubramanian [this message]
2019-12-16  6:53           ` James Bottomley
2019-12-16 13:05             ` Mimi Zohar
2019-12-16 19:20             ` Lakshmi Ramasubramanian
2019-12-16 21:17               ` James Bottomley
2019-12-16 21:37                 ` Lakshmi Ramasubramanian
2019-12-16 21:52                   ` Lakshmi Ramasubramanian
2019-12-17 22:22                     ` Lakshmi Ramasubramanian
2019-12-18  2:01                       ` James Bottomley
2019-12-18  2:44                         ` Lakshmi Ramasubramanian
2019-12-18  3:00                           ` Lakshmi Ramasubramanian
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=1568ff14-316f-f2c4-84d4-7ca4c0a1936a@linux.microsoft.com \
    --to=nramas@linux.microsoft.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=sashal@kernel.org \
    --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

all inboxes | Powered by JetHome®