linux-kernel - Futexes and network filesystems.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1ir3wr0jj.fsf_-_@ebiederm.dsl.xmission.com>
Date:	Tue, 20 Nov 2007 15:53:52 -0700
From:	ebiederm@...ssion.com (Er ic W. Biederman)
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Hansen <haveblue@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Emelyanov <xemul@...nvz.org>,
	Ulrich Drepper <drepper@...hat.com>,
	linux-kernel@...r.kernel.org,
	"Dinakar Guniguntala [imap]" <dino@...ibm.com>,
	Sripathi Kodi <sripathik@...ibm.com>
Subject: Futexes and network filesystems.

Ingo Molnar <mingo@...e.hu> writes:

> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
>> On Fri, 2 Nov 2007, Dave Hansen wrote:
>> > 
>> > There are certainly more of these, but here is one In the futex 
>> > userspace address, we install the current pid's vnr into a userspace 
>> > address.
>> 
>> Now, realistically, why not just say "you can't use these things 
>> across namespaces"? Does anybody really care? After all, somebody who 
>> screws this up only screws himself, not anybody else.
>
> i see two main categories of problems:
>
> - one problem is that this condition is 'invisible'.
>
> - so via this we isolate an important category of syscalls from
>   cross-namespace use perhaps forever.

I had a chance to think about this a bit more, and realized that
the problem is that futexes don't appear to work on network
filesystems, even if the network filesystems provide coherent shared
memory.

It seems to me that we need to have a call that gets a unique token
for a process for each filesystem per filesystem for use in futexes
(especially robust futexes).  Say get_fs_task_id(const char *path);

On local filesystems this could just be the pid as we use today, but
for filesystems that can be accessed from contexts with potentially
overlapping pid values this could be something else.  It is an extra
syscall in the preparation path, but it should be hardly more
expensive the current getpid().

Once we have fixed the futex infrastructure to be able to handle
futexes on network filesystems, the pid namespace case will be trivial
to implement.

Eric

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