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]

Date:	9 Jun 2011 00:43:54 -0400
From:	"George Spelvin" <linux@...izon.com>
To:	eric.dumazet@...il.com, luto@....edu
Cc:	david@...advisors.com, dvhart@...ux.intel.com,
	kyle@...fetthome.net, linux-kernel@...r.kernel.org,
	linux@...izon.com
Subject: Re: Change in functionality of futex() system call.

> You can not prevent DOS on a machine if you allow a process to RO map
> your critical files (where you put futexes), because you allow this
> process to interfere with critical cache lines bouncing between cpus.
> 
> Really, please forget about this crazy idea of allowing foreigners to
> _read_ or memory _map_ your files. Don't do it.

Hold on.  There's a significant difference between making a system
run slowly (there are a hundred ways to achieve that, starting with
the classic fork bomb), and a permanent hard lockup caused by losing
a FUTEX_WAIT.

Among other things, you can notice a DoS after a while and kill it.
Things should then return to normal.

There may well be a reason to share a file containing futexes read-only.

Just for example, consider a circular buffer that a few (trusted)
processes can write to, but many (less trusted) can read.  Obviously,
being able to sleep on the head pointer is useful.

We are already dealing with one problem caused by a too-narrow idea of
how futexes would be used.  Let's not add another "nobody would ever
want to do that!" unnecessarily.
--
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/