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

Date:	Thu, 9 Jun 2011 08:12:56 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Darren Hart <dvhart@...ux.intel.com>,
	George Spelvin <linux@...izon.com>, david@...advisors.com,
	kyle@...fetthome.net, linux-kernel@...r.kernel.org
Subject: Re: Change in functionality of futex() system call.

On Thu, Jun 9, 2011 at 1:11 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> Le jeudi 09 juin 2011 à 00:10 -0400, Andrew Lutomirski a écrit :
>> On Wed, Jun 8, 2011 at 11:54 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>> >
>> > 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.
>>
>> The cacheline bounce DoS slows things down and they go back to normal
>> when you kill the DoS-ing task.
>>
>> The wakeup-eating DoS is permanent.  Seems a good deal worse to me.
>>
>> If you make this change, please at least document it in the man page.
>>
>
>
> This is how futexes had working for years.
>
> It was very obvious from the beginning. Please submit a man page change
> since you raised the point. You own the credit to open a CVE and
> immediately release a fix to all 2.6 versions !
>
> How come a critical fix (according to you) went without being noticed
> and documented ?
>

<cynical answer>Because Linux system calls aren't really documented.

It's reasonable to ask people to read a specification of how a system
call works to see if it's well-thought-out, usable, and has good
security properties.

It's also reasonable to ask people to read an implementation of a
system call and check to see that it conforms to the spec.

It's IMO a little less reasonable to ask people to review complicated
mm code to see if the interface it implements is well-designed.

The futex(2) and futex(7) manpages are very incomplete, even
today.</cynical answer>

>
> If its useful, then it needs a futex extension (and this must be
> emulated on old kernels without this extension)

I'm arguing for the extension.  I don't think the kernel has any
obligation to make sure that new use-cases are possible on old
versions, though.

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