linux-kernel - Re: Change in functionality of futex() system call.

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: <1307621108.3941.77.camel@twins>
Date:	Thu, 09 Jun 2011 14:05:08 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Darren Hart <dvhart@...ux.intel.com>,
	David Oliver <david@...advisors.com>,
	linux-kernel@...r.kernel.org,
	Shawn Bohrer <sbohrer@...advisors.com>,
	Zachary Vonler <zvonler@...advisors.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Hugh Dickins <hughd@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: Change in functionality of futex() system call.

On Mon, 2011-06-06 at 20:11 +0200, Eric Dumazet wrote:

> Now, what if other software uses a MAP_PRIVATE ro mapping ?
> 
> It was working in previous kernels as well.
> 
> We can say its stupid, but IMHO its not.
> 
> In other words, this program should work, if process never touches
> (writes) into first page.
> 
> This program on previous kernels gave :
> rc=-1 errno=11
> (allowing to wait for a value change and a futex_WAKE)
> 
> With new kernel :
> rc=-1 errno=14  [ no sleep allowed ]

Yeah, so friggin what? I can write a similar program that is broken with
the old behaviour. The fact that the semantics are just crap (wtf does
it mean to FUTEX_WAIT on a address that changes mapping on COW) should
be enough to convince you that the old behaviour simply doesn't make
sense.

Once the COW happened you shouldn't be able to observe the old page, yet
that's exactly what the still pending FUTEX_WAIT will do.

The fact that this can happen, means the behaviour is broken, no if else
or buts about it.
--
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/