linux-kernel - Re: POSIX mutex destruction requirements vs. futexes

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: <CA+55aFxgDALOqxzaFC6bNNmyHQ+FEPQ7x5C1vF6S5oY49gKKnw@mail.gmail.com>
Date:	Mon, 1 Dec 2014 13:31:29 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Torvald Riegel <triegel@...hat.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: POSIX mutex destruction requirements vs. futexes

On Mon, Dec 1, 2014 at 12:44 PM, Torvald Riegel <triegel@...hat.com> wrote:
>
> User space could introduce a wrapper (e.g., glibc could provide a futex
> wrapper that allows spurious wakeup on return of 0) -- but glibc can't
> prevent users from not using futexes directly and not through the
> wrapper.  Or should it try to intercept direct, non-wrapper uses of the
> futex syscall in some way?

So I don't think we even need to worry about direct users of the futex
system call. They had better know what they are doing.

> I agree, and that's why I mentioned that it may seem odd to fix this on
> the level of the kernel interface.  However, it just seems the best
> approach when considering practice in kernel and user space, the
> by-design futex properties, and the realities of what POSIX requires.

Sure. That said, I think there really are very few cases we need to worry about:

 - the ptreads_mutex implementation itself.

   This is, after all, what 99% of all applications will use. And
here, the only worry is to make sure that glibc (or whatever other
libc) is aware of its own reuse of allocations, and basically know
that it can get into the situation where a reused mutex memory
allocation can effectively see "stale" wakeups. That is, of course,
assuming that the library implementation is the expected racy one.
There *are* ways to avoid the races, although they are generally not
really even worth the bother - just calling futex_wait() in a loop is
the RightThing(tm) to do.

 - other random direct futex users

   Quite frankly, these are few. There are valid and real use cases
(the CLONE_CHILD_CLEARTID interface, for example, expects the user to
use a raw futex), but they tend to be low-level enough that they'd
really better know about this. And again, it should be easy enough to
just loop around FUTEX_WAIT and just reading the value if somebody is
worried about this.

Making the documentation talk about the issue, and making the strong
suggestion to make any FUTEX_WAIT style use just always loop and check
the actual value for simplicity and robustness is probably the right
approach.

               Linus
--
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/