lkml.org 
[lkml]   [2012]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@chromium.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@linutronix.de>
>>> Signed-off-by: Kees Cook <keescook@chromium.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@redhat.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
>
> .
>



\
 
 \ /
  Last update: 2012-03-30 08:19    [W:0.067 / U:0.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site