From: Casey Schaufler <casey@schaufler-ca.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Andi Kleen <andi@firstfloor.org>,
jmorris@namei.org, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org,
Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH] SMACK: Add missing rcu_read_lock/unlock for process capability walk.
Date: Wed, 20 Apr 2011 16:43:33 -0700 [thread overview]
Message-ID: <4DAF6FA5.7080801@schaufler-ca.com> (raw)
In-Reply-To: <20110420231859.GB32402@tassilo.jf.intel.com>
On 4/20/2011 4:18 PM, Andi Kleen wrote:
> On Wed, Apr 20, 2011 at 03:51:41PM -0700, Casey Schaufler wrote:
>> On 4/20/2011 3:00 PM, Andi Kleen wrote:
>>> From: Andi Kleen <ak@linux.intel.com>
>>>
>>> smk_access_entry does a RCU list walk for a list shared with other
>>> threads. It relies on the caller doing rcu_read_lock().
>>> One caller forgot to do to this, which could lead to races
>>> on preemptible kernels.
>>>
>>> Move the rcu_read_lock() into smk_access_entry instead.
>> Nacked-by: Casey Schaufler <casey@schaufler-ca.com>
>>
>> The lock was moved out of smk_access_entry in support of the
>> processing done in the smack_mmap_file() hook. Where do you see
>> a potential race, and which caller "forgot" to do the lock?
> There are two callers and only one takes it.
There are two callers in smack_access.c.
There are four more in smack_lsm.c
> The one that doesn't take it is smk_curacc.
The call in smk_curacc() is using the task local list, not the system list.
> I checked the callers of that and there is no rcu_read_lock() in those
>
> As far as I understand the cred which holds this list is shared
> between threads and other threads can modify it. Which means
> it needs RCU read lock protection.
The global list, yes. The task specific list, no. Modifying the local
list is like any other modification of the cred structure and requires
the cred be copied.
Moving the lock into smk_access_entry() would introduce a potential
deadlock in smack_mmap_file. There is a bit of convolution in the
mmap hook that requires looking at the list in a way that does not
allow the locking to be embedded where it used to be.
> -Andi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
next prev parent reply other threads:[~2011-04-20 23:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-20 22:00 [PATCH] SMACK: Add missing rcu_read_lock/unlock for process capability walk Andi Kleen
2011-04-20 22:51 ` Casey Schaufler
2011-04-20 23:18 ` Andi Kleen
2011-04-20 23:43 ` Casey Schaufler [this message]
2011-04-21 0:08 ` Andi Kleen
2011-04-21 0:47 ` Casey Schaufler
2011-04-21 15:58 ` Andi Kleen
2011-04-22 3:55 ` Casey Schaufler
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=4DAF6FA5.7080801@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox