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

[Andrew Lutomirski <luto@mit.edu>]

On Thu, Jun 9, 2011 at 1:11 AM, Eric Dumazet <eric.dumazet@gmail.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@gmail.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