linux-kernel - Re: [PATCH v4 2/2] IMA: Call workqueue functions to measure queued keys

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]

Message-ID: <1576639480.14900.13.camel@HansenPartnership.com>
Date:   Wed, 18 Dec 2019 12:24:40 +0900
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
        zohar@...ux.ibm.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 v4 2/2] IMA: Call workqueue functions to measure queued
 keys

On Tue, 2019-12-17 at 19:00 -0800, Lakshmi Ramasubramanian wrote:
> On 12/17/2019 6:44 PM, Lakshmi Ramasubramanian wrote:
> 
> > > 
> > > The direct implication of the comment and the lock dance with the
> > > temporary list and the processed flag is that stuff can be added
> > > to the ima_keys list after you drop the mutex.  Your explanation
> > > in the prior couple of emails says that nothing can be added
> > > because the ima_process_keys flag setting prevents it.  If the
> > > latter is true, you can simply drop the lock after setting the
> > > flag and rely on ima_keys not changing to run it through
> > > process_buffer_measurement without needing any of the
> > > intermediate list or the processed flag.  If the latter isn't
> > > true then any key added to ima_keys after the mutex
> > > is dropped is never processed.
> > > 
> > > James
> 
> One more scenario needs to be taken care - that still doesn't require
> a temp list, but will need a local flag.
> 
> Say, two threads race to call ima_process_queued_keys().
> Both find ima_process_keys flag is false.
> They now race to take to the lock.
> Only the 1st one setting the flag to true should process queued keys.

Kernel developers are systems people ... this is what we do with bit
test and set ... but the API is definitely less friendly than boolean
flags.

James