All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: "spender-JNS0hek0TMl4qEwOxq4T+Q@public.gmane.org"
	<spender-JNS0hek0TMl4qEwOxq4T+Q@public.gmane.org>,
	Peter Zijlstra
	<a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>,
	"linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>,
	Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	"kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org"
	<kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Gene Cooperman <gene-1vnkWVZi4QaVc3sceRu5cw@public.gmane.org>,
	Randy Dunlap <rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>,
	"Eric W. Biederman"
	<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
	Cyrill Gorcunov
	<gorcunov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	Linux Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Subject: Re: [PATCH v2] futex: mark get_robust_list as deprecated
Date: Fri, 30 Mar 2012 10:14:07 +0400	[thread overview]
Message-ID: <4F754F2F.7000600@parallels.com> (raw)
In-Reply-To: <20120330050544.GA32299-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>

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-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
>>> Signed-off-by: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> +
>>> +----------------------------
>>> +
>>> +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
> 
> .
> 

WARNING: multiple messages have this Message-ID (diff)
From: Pavel Emelyanov <xemul@parallels.com>
To: Matt Helsley <matthltc@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Kees Cook <keescook@chromium.org>,
	"spender@grsecurity.net" <spender@grsecurity.net>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Jiri Kosina <jkosina@suse.cz>,
	Darren Hart <dvhart@linux.intel.com>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Linux Containers <containers@lists.linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Gene Cooperman <gene@ccs.neu.edu>
Subject: Re: [PATCH v2] futex: mark get_robust_list as deprecated
Date: Fri, 30 Mar 2012 10:14:07 +0400	[thread overview]
Message-ID: <4F754F2F.7000600@parallels.com> (raw)
In-Reply-To: <20120330050544.GA32299@count0.beaverton.ibm.com>

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
> 
> .
> 


WARNING: multiple messages have this Message-ID (diff)
From: Pavel Emelyanov <xemul@parallels.com>
To: Matt Helsley <matthltc@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Kees Cook <keescook@chromium.org>,
	"spender@grsecurity.net" <spender@grsecurity.net>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Jiri Kosina <jkosina@suse.cz>,
	Darren Hart <dvhart@linux.intel.com>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Linux Containers <containers@lists.linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Gene Cooperman <gene@ccs.neu.edu>
Subject: [kernel-hardening] Re: [PATCH v2] futex: mark get_robust_list as deprecated
Date: Fri, 30 Mar 2012 10:14:07 +0400	[thread overview]
Message-ID: <4F754F2F.7000600@parallels.com> (raw)
In-Reply-To: <20120330050544.GA32299@count0.beaverton.ibm.com>

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
> 
> .
> 

  parent reply	other threads:[~2012-03-30  6:14 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-19 23:12 [PATCH] futex: do not leak robust list to unprivileged process Kees Cook
2012-03-19 23:12 ` [kernel-hardening] " Kees Cook
2012-03-20 13:31 ` Serge Hallyn
2012-03-20 13:31   ` [kernel-hardening] " Serge Hallyn
2012-03-20 17:02   ` Thomas Gleixner
2012-03-20 17:02     ` [kernel-hardening] " Thomas Gleixner
2012-03-20 17:11     ` Kees Cook
2012-03-20 17:11       ` [kernel-hardening] " Kees Cook
2012-03-20 17:23       ` Ingo Molnar
2012-03-20 17:23         ` [kernel-hardening] " Ingo Molnar
2012-03-22 23:46         ` Thomas Gleixner
2012-03-22 23:46           ` [kernel-hardening] " Thomas Gleixner
2012-03-23 17:58           ` [PATCH] futex: mark get_robust_list as deprecated Kees Cook
2012-03-23 17:58             ` [kernel-hardening] " Kees Cook
2012-03-23 18:27             ` Thomas Gleixner
2012-03-23 18:27               ` [kernel-hardening] " Thomas Gleixner
2012-03-23 19:08               ` Kees Cook
2012-03-23 19:08                 ` [kernel-hardening] " Kees Cook
2012-03-23 19:08               ` [PATCH v2] " Kees Cook
2012-03-23 19:08                 ` [kernel-hardening] " Kees Cook
     [not found]                 ` <20120323190855.GA27213-0X9Bc/hWBUTk6RaD4rd5nQ@public.gmane.org>
2012-03-23 22:06                   ` Eric W. Biederman
2012-03-23 22:06                     ` [kernel-hardening] " Eric W. Biederman
2012-03-23 22:06                     ` Eric W. Biederman
     [not found]                     ` <m1fwczvuph.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2012-03-23 22:10                       ` Kees Cook
2012-03-23 22:10                         ` [kernel-hardening] " Kees Cook
2012-03-23 22:10                         ` Kees Cook
2012-03-30  5:05                       ` Matt Helsley
2012-03-30  5:05                         ` [kernel-hardening] " Matt Helsley
2012-03-30  5:05                         ` Matt Helsley
     [not found]                         ` <20120330050544.GA32299-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>
2012-03-30  6:14                           ` Pavel Emelyanov [this message]
2012-03-30  6:14                             ` [kernel-hardening] " Pavel Emelyanov
2012-03-30  6:14                             ` Pavel Emelyanov
2012-03-30 22:51                           ` Gene Cooperman
2012-03-30 22:51                         ` Gene Cooperman
2012-03-30 22:51                           ` [kernel-hardening] " Gene Cooperman
2012-03-27 18:05                 ` Josh Boyer
2012-03-27 18:05                   ` [kernel-hardening] " Josh Boyer
2012-03-27 19:13                   ` Peter Zijlstra
2012-03-27 19:13                     ` [kernel-hardening] " Peter Zijlstra
2012-03-29  9:56                 ` [tip:core/locking] futex: Mark " tip-bot for Kees Cook
2012-08-02 10:35                 ` [PATCH v2] futex: mark " richard -rw- weinberger
2012-08-02 10:35                   ` [kernel-hardening] " richard -rw- weinberger
2012-08-02 11:11                   ` Eric W. Biederman
2012-08-02 11:11                     ` [kernel-hardening] " Eric W. Biederman
2012-08-03 10:17                     ` richard -rw- weinberger
2012-08-03 10:17                       ` [kernel-hardening] " richard -rw- weinberger
2012-08-03 11:02                       ` Cyrill Gorcunov
2012-08-03 11:02                         ` [kernel-hardening] " Cyrill Gorcunov
2012-08-03 11:19                         ` richard -rw- weinberger
2012-08-03 11:19                           ` [kernel-hardening] " richard -rw- weinberger
2012-08-03 11:27                           ` Cyrill Gorcunov
2012-08-03 11:27                             ` [kernel-hardening] " Cyrill Gorcunov
2012-08-03 11:30                             ` richard -rw- weinberger
2012-08-03 11:30                               ` [kernel-hardening] " richard -rw- weinberger
2012-08-03 11:35                               ` Cyrill Gorcunov
2012-08-03 11:35                                 ` [kernel-hardening] " Cyrill Gorcunov
2012-08-03 11:38                                 ` richard -rw- weinberger
2012-08-03 11:38                                   ` [kernel-hardening] " richard -rw- weinberger
2012-08-03 12:38                         ` Pavel Emelyanov
2012-08-03 12:38                           ` [kernel-hardening] " Pavel Emelyanov
2012-08-03 12:58                           ` Eric W. Biederman
2012-08-03 12:58                             ` [kernel-hardening] " Eric W. Biederman
2012-08-03 13:00                             ` richard -rw- weinberger
2012-08-03 13:00                               ` [kernel-hardening] " richard -rw- weinberger
2012-08-03 17:16                             ` Kees Cook
2012-08-03 17:16                               ` [kernel-hardening] " Kees Cook
2012-08-03 18:06                               ` [kernel-hardening] [PATCH] Revert "futex: Mark get_robust_list as deprecated" Richard Weinberger
2012-03-28 18:33           ` [PATCH] futex: do not leak robust list to unprivileged process Kees Cook
2012-03-28 18:33             ` [kernel-hardening] " Kees Cook
2012-03-28 21:24             ` Thomas Gleixner
2012-03-28 21:24               ` [kernel-hardening] " Thomas Gleixner
2012-03-29  9:55 ` [tip:core/locking] futex: Do " tip-bot for Kees Cook
2012-06-19  1:41   ` Wanlong Gao
2012-06-19  2:24     ` Serge Hallyn
2012-06-19  2:32       ` Wanlong Gao
2012-06-19  3:13         ` Serge Hallyn
2012-06-19  3:21           ` Wanlong Gao
2012-06-19 12:23             ` Serge Hallyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F754F2F.7000600@parallels.com \
    --to=xemul-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
    --cc=a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
    --cc=gene-1vnkWVZi4QaVc3sceRu5cw@public.gmane.org \
    --cc=gorcunov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
    --cc=jkosina-AlSwsSmVLrQ@public.gmane.org \
    --cc=keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org \
    --cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
    --cc=rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org \
    --cc=spender-JNS0hek0TMl4qEwOxq4T+Q@public.gmane.org \
    --cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.