From: Darren Hart <dvhltc@us.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.cz>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
Nick Piggin <npiggin@suse.de>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] futex: futex_find_get_task make credentials check conditional
Date: Tue, 29 Jun 2010 09:58:15 -0700 [thread overview]
Message-ID: <4C2A2627.3080408@us.ibm.com> (raw)
In-Reply-To: <AANLkTinyoyZVg8iYOuUx6aA4XlUlLywl4q6GLXmeYP-x@mail.gmail.com>
On 06/29/2010 09:41 AM, Linus Torvalds wrote:
> On Tue, Jun 29, 2010 at 1:42 AM, Michal Hocko<mhocko@suse.cz> wrote:
>>
>> futex_find_get_task is currently used (through lookup_pi_state) from two
>> contexts, futex_requeue and futex_lock_pi_atomic. While credentials check
>> makes sense in the first code path, the second one is more problematic
>> because this check requires that the PI lock holder (pid parameter) has
>> the same uid and euid as the process's euid which is trying to lock the
>> same futex (current).
>
> So exactly why does it make sense to check the credentials in the
> first code path then? Shouldn't the futex issue in the end depend on
> whether you have a shared page or not - and not on credentials at all?
> Any two processes that share a futex in the same shared page should be
> able to use that without any regard for whether they are the same
> user. That's kind of the point, no?
I agree and haven't been able to come up with a need for the test
either, but I wanted to hear back from Ingo as the he authored the
original check.
I was trying to see if futex_lock_pi() could somehow be abused, but if
so, I don't see it:
TaskUserA TaskUserB
futex_lock_pi(addrA)
*addrB = TID_OF(TaskUserA)
futex_lock_pi(addrB)
TaskUserB would lookup the pi_state, not find it as addrB and addrA
don't hash to the same key, create a new pi_state and mark TaskUserA as
the owner, then block.
Once TaskUserA exits, the pi_list will contain the pi_state for the
addrB futex. This is "bad", but the kernel cleans it up, releases the
lock - but doesn't wake TaskUserB. That seems acceptable to me since
TaskUserB is in the wrong here.
> IOW, I personally dislike these kinds of conditional checks,
> especially since the discussion (at least the part I've seen) hasn't
> made it clear why it should be conditional - or exist - in the first
> place.
>
> So I'd like the patch to include an explanation of exactly why the two
> cases are different.
Agreed, waiting on Ingo at the moment.
> The other thing I'd like to see is to move the whole cred checking up
> a level. There's no reason to check the credentials in
> futex_find_get_task() that I can see - why not do it in the caller
> instead? IOW, I think futex_find_get_task() should just look something
> like this instead:
/me beats head on desk, duh. Still, I'm hoping this isn't necessary and
we can lose the credentials checking entirely.
Thanks,
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
next prev parent reply other threads:[~2010-06-29 16:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-23 9:13 futex: race in lock and unlock&exit for robust futex with PI? Michal Hocko
2010-06-25 2:42 ` Darren Hart
2010-06-25 8:27 ` Michal Hocko
2010-06-25 17:53 ` Darren Hart
2010-06-25 23:35 ` Darren Hart
2010-06-28 14:42 ` Michal Hocko
2010-06-28 14:56 ` Darren Hart
2010-06-28 15:32 ` Michal Hocko
2010-06-28 15:40 ` Michal Hocko
2010-06-28 15:58 ` Michal Hocko
2010-06-28 16:39 ` Michal Hocko
2010-06-28 16:45 ` Peter Zijlstra
2010-06-28 16:56 ` Michal Hocko
2010-06-28 16:49 ` Peter Zijlstra
2010-06-29 8:42 ` [PATCH] futex: futex_find_get_task make credentials check conditional Michal Hocko
2010-06-29 14:56 ` Darren Hart
2010-06-29 15:24 ` Michal Hocko
2010-06-29 16:41 ` Linus Torvalds
2010-06-29 16:58 ` Darren Hart [this message]
2010-06-29 18:03 ` Thomas Gleixner
2010-06-30 7:01 ` Michal Hocko
2010-06-30 9:55 ` [PATCH] futex: futex_find_get_task remove credentails check Michal Hocko
2010-06-30 16:43 ` Darren Hart
2010-07-08 9:28 ` Michal Hocko
2010-07-08 9:32 ` Ingo Molnar
2010-07-08 9:39 ` Michal Hocko
2010-07-08 9:43 ` Peter Zijlstra
2010-07-08 9:50 ` Michal Hocko
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=4C2A2627.3080408@us.ibm.com \
--to=dvhltc@us.ibm.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.cz \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.