Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 30 Mar 2012 10:14:07 +0400
From: Pavel Emelyanov <xemul@...allels.com>
To: Matt Helsley <matthltc@...ibm.com>
CC: "Eric W. Biederman" <ebiederm@...ssion.com>,
        Kees Cook <keescook@...omium.org>,
        "spender@...ecurity.net" <spender@...ecurity.net>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        Jiri Kosina <jkosina@...e.cz>, Darren Hart <dvhart@...ux.intel.com>,
        "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        David Howells <dhowells@...hat.com>,
        Randy Dunlap <rdunlap@...otime.net>,
        Linux Containers <containers@...ts.linux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Cyrill Gorcunov <gorcunov@...nvz.org>,
        Gene Cooperman <gene@....neu.edu>
Subject: Re: [PATCH v2] futex: mark get_robust_list as deprecated

On 03/30/2012 09:05 AM, Matt Helsley wrote:
> On Fri, Mar 23, 2012 at 03:06:02PM -0700, Eric W. Biederman wrote:
>> Kees Cook <keescook@...omium.org> writes:
>>
>>> Notify get_robust_list users that the syscall is going away.
>>
>> Has anyone asked the question if the folks working on checkpoint/restart
>> are going to need this.
>>
>> This seems like important information to know if you want to checkpoint
>> a process.
> 
> I have no idea if the CRIU and DMTCP folks care about this. I've added
> some folks related to those projects to the Cc list.

Nope, we don't need this syscall, thanks for notifying!

>>
>> Eric
>>
>>> Suggested-by: Thomas Gleixner <tglx@...utronix.de>
>>> Signed-off-by: Kees Cook <keescook@...omium.org>
>>> ---
>>> v2:
>>>  - add note to feature-removal-schedule.txt.
>>> ---
>>>  Documentation/feature-removal-schedule.txt |   10 ++++++++++
>>>  kernel/futex.c                             |    2 ++
>>>  kernel/futex_compat.c                      |    2 ++
>>>  3 files changed, 14 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
>>> index 4bfd982..e3bf119 100644
>>> --- a/Documentation/feature-removal-schedule.txt
>>> +++ b/Documentation/feature-removal-schedule.txt
>>> @@ -543,3 +543,13 @@ When:	3.5
>>>  Why:	The old kmap_atomic() with two arguments is deprecated, we only
>>>  	keep it for backward compatibility for few cycles and then drop it.
>>>  Who:	Cong Wang <amwang@...hat.com>
>>> +
>>> +----------------------------
>>> +
>>> +What:	get_robust_list syscall
>>> +When:	2013
>>> +Why:	There appear to be no production users of the get_robust_list syscall,
>>> +	and it runs the risk of leaking address locations, allowing the bypass
>>> +	of ASLR. It was only ever intended for debugging, so it should be
>>> +	removed.
> 
> So I've looked in glibc, gdb, and DMTCP. The description of the intended
> use of get_robust_list() is accurate. However the benefit of ASLR is
> less clear when it comes to the robust list. In glibc the robust list is
> only used from NPTL. The robust list head is in struct pthread which can be
> obtained from pthread_self() anyway. Thus I think ASLR doesn't really help
> obfuscate the robust futex list unless the program is using robust futexes
> without the aid of glibc.
> 
> Cheers,
> 	-Matt Helsley
> 
> .
> 

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.