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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ