linux-kernel - Re: [PATCH v3 1/2] IMA: Define workqueue for early boot "key" measurements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sun, 15 Dec 2019 07:44:37 -0500
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
        linux-integrity@...r.kernel.org
Cc:     eric.snowberg@...cle.com, dhowells@...hat.com,
        mathew.j.martineau@...ux.intel.com, matthewgarrett@...gle.com,
        sashal@...nel.org, jamorris@...ux.microsoft.com,
        linux-kernel@...r.kernel.org, keyrings@...r.kernel.org
Subject: Re: [PATCH v3 1/2] IMA: Define workqueue for early boot "key"
 measurements

On Fri, 2019-12-13 at 08:06 -0500, Mimi Zohar wrote:
> On Thu, 2019-12-12 at 18:59 -0800, Lakshmi Ramasubramanian wrote:
> > On 12/12/2019 6:32 PM, Mimi Zohar wrote:
> > 
> > >>>
> > >>> Don't you need a test here, before setting ima_process_keys?
> > >>>
> > >>> 	if (ima_process_keys)
> > >>> 		return;
> 
> > >> That check is done before the comment - at the start of
> > >> ima_process_queued_keys().
> > > 
> > > The first test prevents taking the mutex unnecessarily.
> > > 
> > 
> > I am trying to understand your concern here. Could you please clarify?
> > 
> >   => If ima_process_keys is false
> >        -> With the mutex held, should check ima_process_keys again 
> > before setting?
> > 
> > Let's say 2 or more threads are racing in calling ima_process_queued_keys():
> > 
> > The 1st one will set ima_process_keys and process queued keys.
> > 
> > The 2nd and subsequent ones - even if they have gone past the initial 
> > check, will find an empty list of keys (the list "ima_keys") when they 
> > take the mutex. So they'll not process any keys.
> 
> I just need to convince myself that this is correct.  Normally before
> reading and writing a flag, there is some sort of locking.  With
> taking the mutex before setting the flag, there is now only a lock
> around the single writer.
> 
> Without taking a lock before reading the flag, will the queue always
> be empty is the question.  If it is, then the comment is correct, but
> the code assumes not and processes the list again.  Testing the flag
> after taking the mutex just re-enforces the comment.
> 
> Bottom line, does reading the flag need to be lock protected?

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.

Mimi