linux-kernel - Re: [PATCH] RFC: futex fault handling and futex key references (NOT FOR INCLUSION)

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <1231538564.29452.16.camel@twins>
Date:	Fri, 09 Jan 2009 23:02:44 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Darren Hart <dvhltc@...ibm.com>
Cc:	linux-kernel@...r.kernel.org, Darren Hart <dvhltc@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Nick Piggin <npiggin@...e.de>
Subject: Re: [PATCH] RFC: futex fault handling and futex key references
 (NOT FOR INCLUSION)

On Thu, 2009-01-08 at 23:52 -0800, Darren Hart wrote:
> While trying to bend my brain around the various layers of fault handling in
> futex.c, I think I may have uncovered some logical errors (or at least stale
> code sections).  I've attached two patches that address the alleged problems
> against linux-tip/core/futexes.  They are based on the following assumption:
> 
> Since the uaddr passed to a futex function isn't updated within the function,
> and the mm doesn't change while we're in there, 

That's not quite true, you _can_ change the memory map by issuing
concurrent mmap/munmap/mremap etc.. calls from another thread.

The thing is, afaik futexes have never been completely safe wrt
concurrent mm modifications -- that is, as long as we fail the futex op
with -EFAULT or similar and not crash the kernel we're good.

> there should never be a need to
> make repeat calls to futex_get_key().  Even if the queue_lock is dropped, the
> futex_q might lose it's waiter (requeued) but the key stays the same.

Yes, so when we assume the mmap stable (and fail the op whenever that
assumption proves false) we can say the futex keys are stable and should
never need recomputation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/