Mailing List Archive: Linux: Kernel

[PATCH v2] futex: mark get_robust_list as deprecated

Index | Next | Previous | View Threaded

keescook at chromium

Mar 23, 2012, 12:08 PM

Post #1 of 21 (161 views)
Permalink

[PATCH v2] futex: mark get_robust_list as deprecated

Notify get_robust_list users that the syscall is going away.

Suggested-by: Thomas Gleixner <tglx [at] linutronix>
Signed-off-by: Kees Cook <keescook [at] chromium>
---
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 [at] redhat>
+
+----------------------------
+
+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.
+Who: Kees Cook <keescook [at] chromium>
diff --git a/kernel/futex.c b/kernel/futex.c
index d701be5..e2b0fb9 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2449,6 +2449,8 @@ SYSCALL_DEFINE3(get_robust_list, int, pid,
if (!futex_cmpxchg_enabled)
return -ENOSYS;

+ WARN_ONCE(1, "deprecated: get_robust_list will be deleted in 2013.\n");
+
rcu_read_lock();

ret = -ESRCH;
diff --git a/kernel/futex_compat.c b/kernel/futex_compat.c
index a9642d5..83e368b 100644
--- a/kernel/futex_compat.c
+++ b/kernel/futex_compat.c
@@ -142,6 +142,8 @@ compat_sys_get_robust_list(int pid, compat_uptr_t __user *head_ptr,
if (!futex_cmpxchg_enabled)
return -ENOSYS;

+ WARN_ONCE(1, "deprecated: get_robust_list will be deleted in 2013.\n");
+
rcu_read_lock();

ret = -ESRCH;
--
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

ebiederm at xmission

Mar 23, 2012, 3:06 PM

Post #2 of 21 (155 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

Kees Cook <keescook [at] chromium> 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.

Eric

> Suggested-by: Thomas Gleixner <tglx [at] linutronix>
> Signed-off-by: Kees Cook <keescook [at] chromium>
> ---
> 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 [at] redhat>
> +
> +----------------------------
> +
> +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.
> +Who: Kees Cook <keescook [at] chromium>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index d701be5..e2b0fb9 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -2449,6 +2449,8 @@ SYSCALL_DEFINE3(get_robust_list, int, pid,
> if (!futex_cmpxchg_enabled)
> return -ENOSYS;
>
> + WARN_ONCE(1, "deprecated: get_robust_list will be deleted in 2013.\n");
> +
> rcu_read_lock();
>
> ret = -ESRCH;
> diff --git a/kernel/futex_compat.c b/kernel/futex_compat.c
> index a9642d5..83e368b 100644
> --- a/kernel/futex_compat.c
> +++ b/kernel/futex_compat.c
> @@ -142,6 +142,8 @@ compat_sys_get_robust_list(int pid, compat_uptr_t __user *head_ptr,
> if (!futex_cmpxchg_enabled)
> return -ENOSYS;
>
> + WARN_ONCE(1, "deprecated: get_robust_list will be deleted in 2013.\n");
> +
> rcu_read_lock();
>
> ret = -ESRCH;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

keescook at chromium

Mar 23, 2012, 3:10 PM

Post #3 of 21 (160 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On Fri, Mar 23, 2012 at 3:06 PM, Eric W. Biederman
<ebiederm [at] xmission> wrote:
> Kees Cook <keescook [at] chromium> 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.

Hm, that might be true. But, I guess that's why it's lucky it's a
separate patch. :) The first patch is still desirable, IMO.

-Kees

--
Kees Cook
ChromeOS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jwboyer at gmail

Mar 27, 2012, 11:05 AM

Post #4 of 21 (155 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On Fri, Mar 23, 2012 at 3:08 PM, Kees Cook <keescook [at] chromium> wrote:
> Notify get_robust_list users that the syscall is going away.
>
> Suggested-by: Thomas Gleixner <tglx [at] linutronix>
> Signed-off-by: Kees Cook <keescook [at] chromium>
> ---
> 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 [at] redhat>
> +
> +----------------------------
> +
> +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.
> +Who: � Kees Cook <keescook [at] chromium>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index d701be5..e2b0fb9 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -2449,6 +2449,8 @@ SYSCALL_DEFINE3(get_robust_list, int, pid,
> � � � �if (!futex_cmpxchg_enabled)
> � � � � � � � �return -ENOSYS;
>
> + � � � WARN_ONCE(1, "deprecated: get_robust_list will be deleted in 2013.\n");
> +

Do you really need WARN_ONCE? It's going to spew a backtrace if this
is called, and that is going to cause various auto-bug reporters to file
bugs as well. There's nothing that can be done with those bugs other
than to wait until this is removed. Maybe it won't trigger because
nobody is using it, but ugh.

Is printk_once sufficient?

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

a.p.zijlstra at chello

Mar 27, 2012, 12:13 PM

Post #5 of 21 (156 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On Tue, 2012-03-27 at 14:05 -0400, Josh Boyer wrote:
>
> Do you really need WARN_ONCE? It's going to spew a backtrace if this
> is called, and that is going to cause various auto-bug reporters to file
> bugs as well.

That's a positive, right? That gives extra visibility to who and what
might possibly use this thing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

matthltc at us

Mar 29, 2012, 10:05 PM

Post #6 of 21 (148 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On Fri, Mar 23, 2012 at 03:06:02PM -0700, Eric W. Biederman wrote:
> Kees Cook <keescook [at] chromium> 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.

>
> Eric
>
> > Suggested-by: Thomas Gleixner <tglx [at] linutronix>
> > Signed-off-by: Kees Cook <keescook [at] chromium>
> > ---
> > 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 [at] redhat>
> > +
> > +----------------------------
> > +
> > +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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

xemul at parallels

Mar 29, 2012, 11:14 PM

Post #7 of 21 (149 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

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 [at] chromium> 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 [at] linutronix>
>>> Signed-off-by: Kees Cook <keescook [at] chromium>
>>> ---
>>> 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 [at] redhat>
>>> +
>>> +----------------------------
>>> +
>>> +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
>
> .
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

gene at ccs

Mar 30, 2012, 3:51 PM

Post #8 of 21 (151 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

Thanks for including us in the cc, Matt.
We don't need the system call for DMTCP either.

Also, in our DMTCP user base, we haven't had any requests to support
checkpointing of user code with get_robust_list(). If a user had needed
this or a similar system call, I suspect our new plugin architecture
would make it easy to eupport. But it's a non-issue now.

Thanks,
- Gene

On Thu, Mar 29, 2012 at 10:05:44PM -0700, Matt Helsley wrote:
> On Fri, Mar 23, 2012 at 03:06:02PM -0700, Eric W. Biederman wrote:
> > Kees Cook <keescook [at] chromium> 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.
>
> >
> > Eric
> >
> > > Suggested-by: Thomas Gleixner <tglx [at] linutronix>
> > > Signed-off-by: Kees Cook <keescook [at] chromium>
> > > ---
> > > 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 [at] redhat>
> > > +
> > > +----------------------------
> > > +
> > > +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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

richard.weinberger at gmail

Aug 2, 2012, 3:35 AM

Post #9 of 21 (124 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On Fri, Mar 23, 2012 at 8:08 PM, Kees Cook <keescook [at] chromium> wrote:
> Notify get_robust_list users that the syscall is going away.
>
> Suggested-by: Thomas Gleixner <tglx [at] linutronix>
> Signed-off-by: Kees Cook <keescook [at] chromium>
> ---

I'm using this system call in an application and noticed that's marked
as deprecated now.
My application collects all kind of information from crashing programs.
It's installed in /proc/sys/kernel/core_pattern.

If program X is crashing it executes get_robust_list(X) to get the
address of the robust list
and reads the list from /proc/X/mem.

Is there another way to get the robust list from another program (by it's pid)?

--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

ebiederm at xmission

Aug 2, 2012, 4:11 AM

Post #10 of 21 (124 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

richard -rw- weinberger <richard.weinberger [at] gmail> writes:

> On Fri, Mar 23, 2012 at 8:08 PM, Kees Cook <keescook [at] chromium> wrote:
>> Notify get_robust_list users that the syscall is going away.
>>
>> Suggested-by: Thomas Gleixner <tglx [at] linutronix>
>> Signed-off-by: Kees Cook <keescook [at] chromium>
>> ---
>
> I'm using this system call in an application and noticed that's marked
> as deprecated now.
> My application collects all kind of information from crashing programs.
> It's installed in /proc/sys/kernel/core_pattern.
>
> If program X is crashing it executes get_robust_list(X) to get the
> address of the robust list
> and reads the list from /proc/X/mem.
>
> Is there another way to get the robust list from another program (by it's pid)?

The folks doing checkpoint/restart claim to not need this, so there
might be a way either that or they just haven't hit this problem yet.

What you are doing sounds like a reasonable use of get_robust_list to me.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

richard.weinberger at gmail

Aug 3, 2012, 3:17 AM

Post #11 of 21 (124 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On Thu, Aug 2, 2012 at 1:11 PM, Eric W. Biederman <ebiederm [at] xmission> wrote:
> richard -rw- weinberger <richard.weinberger [at] gmail> writes:
>
>> On Fri, Mar 23, 2012 at 8:08 PM, Kees Cook <keescook [at] chromium> wrote:
>>> Notify get_robust_list users that the syscall is going away.
>>>
>>> Suggested-by: Thomas Gleixner <tglx [at] linutronix>
>>> Signed-off-by: Kees Cook <keescook [at] chromium>
>>> ---
>>
>> I'm using this system call in an application and noticed that's marked
>> as deprecated now.
>> My application collects all kind of information from crashing programs.
>> It's installed in /proc/sys/kernel/core_pattern.
>>
>> If program X is crashing it executes get_robust_list(X) to get the
>> address of the robust list
>> and reads the list from /proc/X/mem.
>>
>> Is there another way to get the robust list from another program (by it's pid)?
>
> The folks doing checkpoint/restart claim to not need this, so there
> might be a way either that or they just haven't hit this problem yet.
>
> What you are doing sounds like a reasonable use of get_robust_list to me.
>

CRIU folks, how do you deal with futex robust lists?

--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

gorcunov at openvz

Aug 3, 2012, 4:02 AM

Post #12 of 21 (125 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On Fri, Aug 03, 2012 at 12:17:43PM +0200, richard -rw- weinberger wrote:
> On Thu, Aug 2, 2012 at 1:11 PM, Eric W. Biederman <ebiederm [at] xmission> wrote:
> > richard -rw- weinberger <richard.weinberger [at] gmail> writes:
> >
> >> On Fri, Mar 23, 2012 at 8:08 PM, Kees Cook <keescook [at] chromium> wrote:
> >>> Notify get_robust_list users that the syscall is going away.
> >>>
> >>> Suggested-by: Thomas Gleixner <tglx [at] linutronix>
> >>> Signed-off-by: Kees Cook <keescook [at] chromium>
> >>> ---
> >>
> >> I'm using this system call in an application and noticed that's marked
> >> as deprecated now.
> >> My application collects all kind of information from crashing programs.
> >> It's installed in /proc/sys/kernel/core_pattern.
> >>
> >> If program X is crashing it executes get_robust_list(X) to get the
> >> address of the robust list
> >> and reads the list from /proc/X/mem.
> >>
> >> Is there another way to get the robust list from another program (by it's pid)?
> >
> > The folks doing checkpoint/restart claim to not need this, so there
> > might be a way either that or they just haven't hit this problem yet.
> >
> > What you are doing sounds like a reasonable use of get_robust_list to me.
> >
>
> CRIU folks, how do you deal with futex robust lists?

Well, I believe we were over-optimistic in claiming that we don't need this
syscall (to be fair I think we simply yet not faced the problem Eric points).
So we need some way to fetch this address and set it back. If get_robust_list
get deprecated maybe we could print it out in /proc/pid/stat or something?

Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

richard.weinberger at gmail

Aug 3, 2012, 4:19 AM

Post #13 of 21 (122 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On Fri, Aug 3, 2012 at 1:02 PM, Cyrill Gorcunov <gorcunov [at] openvz> wrote:
>> >> I'm using this system call in an application and noticed that's marked
>> >> as deprecated now.
>> >> My application collects all kind of information from crashing programs.
>> >> It's installed in /proc/sys/kernel/core_pattern.
>> >>
>> >> If program X is crashing it executes get_robust_list(X) to get the
>> >> address of the robust list
>> >> and reads the list from /proc/X/mem.
>> >>
>> >> Is there another way to get the robust list from another program (by it's pid)?
>> >
>> > The folks doing checkpoint/restart claim to not need this, so there
>> > might be a way either that or they just haven't hit this problem yet.
>> >
>> > What you are doing sounds like a reasonable use of get_robust_list to me.
>> >
>>
>> CRIU folks, how do you deal with futex robust lists?
>
> Well, I believe we were over-optimistic in claiming that we don't need this
> syscall (to be fair I think we simply yet not faced the problem Eric points).
> So we need some way to fetch this address and set it back. If get_robust_list
> get deprecated maybe we could print it out in /proc/pid/stat or something?

Kees, you said get_robust_list() can be used to bypass ASLR.
How? What makes it worse than /proc/pid/maps?

If the robust list address itself is bad, removing get_robust_list()
and putting the
information into /proc is useless.

--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

gorcunov at openvz

Aug 3, 2012, 4:27 AM

Post #14 of 21 (124 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On Fri, Aug 03, 2012 at 01:19:24PM +0200, richard -rw- weinberger wrote:
> >>
> >> CRIU folks, how do you deal with futex robust lists?
> >
> > Well, I believe we were over-optimistic in claiming that we don't need this
> > syscall (to be fair I think we simply yet not faced the problem Eric points).
> > So we need some way to fetch this address and set it back. If get_robust_list
> > get deprecated maybe we could print it out in /proc/pid/stat or something?
>
> Kees, you said get_robust_list() can be used to bypass ASLR.
> How? What makes it worse than /proc/pid/maps?
>
> If the robust list address itself is bad, removing get_robust_list()
> and putting the information into /proc is useless.

Look, the /proc entry might check for some CAP and do not allow
a regular user to fetch this address.

Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

richard.weinberger at gmail

Aug 3, 2012, 4:30 AM

Post #15 of 21 (122 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On Fri, Aug 3, 2012 at 1:27 PM, Cyrill Gorcunov <gorcunov [at] openvz> wrote:
> On Fri, Aug 03, 2012 at 01:19:24PM +0200, richard -rw- weinberger wrote:
>> >>
>> >> CRIU folks, how do you deal with futex robust lists?
>> >
>> > Well, I believe we were over-optimistic in claiming that we don't need this
>> > syscall (to be fair I think we simply yet not faced the problem Eric points).
>> > So we need some way to fetch this address and set it back. If get_robust_list
>> > get deprecated maybe we could print it out in /proc/pid/stat or something?
>>
>> Kees, you said get_robust_list() can be used to bypass ASLR.
>> How? What makes it worse than /proc/pid/maps?
>>
>> If the robust list address itself is bad, removing get_robust_list()
>> and putting the information into /proc is useless.
>
> Look, the /proc entry might check for some CAP and do not allow
> a regular user to fetch this address.

We could also add another check to get_robust_list().
It does already ptrace_may_access().

--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

gorcunov at openvz

Aug 3, 2012, 4:35 AM

Post #16 of 21 (120 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On Fri, Aug 03, 2012 at 01:30:31PM +0200, richard -rw- weinberger wrote:
> On Fri, Aug 3, 2012 at 1:27 PM, Cyrill Gorcunov <gorcunov [at] openvz> wrote:
> > On Fri, Aug 03, 2012 at 01:19:24PM +0200, richard -rw- weinberger wrote:
> >> >>
> >> >> CRIU folks, how do you deal with futex robust lists?
> >> >
> >> > Well, I believe we were over-optimistic in claiming that we don't need this
> >> > syscall (to be fair I think we simply yet not faced the problem Eric points).
> >> > So we need some way to fetch this address and set it back. If get_robust_list
> >> > get deprecated maybe we could print it out in /proc/pid/stat or something?
> >>
> >> Kees, you said get_robust_list() can be used to bypass ASLR.
> >> How? What makes it worse than /proc/pid/maps?
> >>
> >> If the robust list address itself is bad, removing get_robust_list()
> >> and putting the information into /proc is useless.
> >
> > Look, the /proc entry might check for some CAP and do not allow
> > a regular user to fetch this address.
>
> We could also add another check to get_robust_list().
> It does already ptrace_may_access().

Yes, and I'm definitely not against that ;) The problem is that this
syscall was marked as deprecated and if people want to drop it we
need to find a way to provide this address back in a sake of c/r.

If c/r is the only _one_ who needs this facility than providing the
address via /proc might be worth thing to do (since I can wrap
it with CONFIG_CHECKPOINT_RESTORE and a regular kernel won't see
this snippet at all).

Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

richard.weinberger at gmail

Aug 3, 2012, 4:38 AM

Post #17 of 21 (123 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On Fri, Aug 3, 2012 at 1:35 PM, Cyrill Gorcunov <gorcunov [at] openvz> wrote:
> On Fri, Aug 03, 2012 at 01:30:31PM +0200, richard -rw- weinberger wrote:
>> On Fri, Aug 3, 2012 at 1:27 PM, Cyrill Gorcunov <gorcunov [at] openvz> wrote:
>> > On Fri, Aug 03, 2012 at 01:19:24PM +0200, richard -rw- weinberger wrote:
>> >> >>
>> >> >> CRIU folks, how do you deal with futex robust lists?
>> >> >
>> >> > Well, I believe we were over-optimistic in claiming that we don't need this
>> >> > syscall (to be fair I think we simply yet not faced the problem Eric points).
>> >> > So we need some way to fetch this address and set it back. If get_robust_list
>> >> > get deprecated maybe we could print it out in /proc/pid/stat or something?
>> >>
>> >> Kees, you said get_robust_list() can be used to bypass ASLR.
>> >> How? What makes it worse than /proc/pid/maps?
>> >>
>> >> If the robust list address itself is bad, removing get_robust_list()
>> >> and putting the information into /proc is useless.
>> >
>> > Look, the /proc entry might check for some CAP and do not allow
>> > a regular user to fetch this address.
>>
>> We could also add another check to get_robust_list().
>> It does already ptrace_may_access().
>
> Yes, and I'm definitely not against that ;) The problem is that this
> syscall was marked as deprecated and if people want to drop it we
> need to find a way to provide this address back in a sake of c/r.
>
> If c/r is the only _one_ who needs this facility than providing the
> address via /proc might be worth thing to do (since I can wrap
> it with CONFIG_CHECKPOINT_RESTORE and a regular kernel won't see
> this snippet at all).

Please see my first mail above.
c/r is not the only user. :-P

--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

xemul at parallels

Aug 3, 2012, 5:38 AM

Post #18 of 21 (121 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On 08/03/2012 03:02 PM, Cyrill Gorcunov wrote:
> On Fri, Aug 03, 2012 at 12:17:43PM +0200, richard -rw- weinberger wrote:
>> On Thu, Aug 2, 2012 at 1:11 PM, Eric W. Biederman <ebiederm [at] xmission> wrote:
>>> richard -rw- weinberger <richard.weinberger [at] gmail> writes:
>>>
>>>> On Fri, Mar 23, 2012 at 8:08 PM, Kees Cook <keescook [at] chromium> wrote:
>>>>> Notify get_robust_list users that the syscall is going away.
>>>>>
>>>>> Suggested-by: Thomas Gleixner <tglx [at] linutronix>
>>>>> Signed-off-by: Kees Cook <keescook [at] chromium>
>>>>> ---
>>>>
>>>> I'm using this system call in an application and noticed that's marked
>>>> as deprecated now.
>>>> My application collects all kind of information from crashing programs.
>>>> It's installed in /proc/sys/kernel/core_pattern.
>>>>
>>>> If program X is crashing it executes get_robust_list(X) to get the
>>>> address of the robust list
>>>> and reads the list from /proc/X/mem.
>>>>
>>>> Is there another way to get the robust list from another program (by it's pid)?
>>>
>>> The folks doing checkpoint/restart claim to not need this, so there
>>> might be a way either that or they just haven't hit this problem yet.
>>>
>>> What you are doing sounds like a reasonable use of get_robust_list to me.
>>>
>>
>> CRIU folks, how do you deal with futex robust lists?
>
> Well, I believe we were over-optimistic in claiming that we don't need this
> syscall (to be fair I think we simply yet not faced the problem Eric points).
> So we need some way to fetch this address and set it back. If get_robust_list
> get deprecated maybe we could print it out in /proc/pid/stat or something?

I agree with Cyrill, sorry for the confusion last time. We do need some way
to get the list location. The exact API is not critical, we can work with
either of the mentioned above.

> Cyrill
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

ebiederm at xmission

Aug 3, 2012, 5:58 AM

Post #19 of 21 (124 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

The permissions on the syscall were fixed them withR ptrace_may_access.

We have identified two legitimate use cases.

It looks like it is time for someone to generate the path to remove the depreciation.

Who is up for writing and testing that patch?

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

richard.weinberger at gmail

Aug 3, 2012, 6:00 AM

Post #20 of 21 (122 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

On Fri, Aug 3, 2012 at 2:58 PM, Eric W. Biederman <ebiederm [at] xmission> wrote:
> The permissions on the syscall were fixed them withR ptrace_may_access.
>
> We have identified two legitimate use cases.
>
> It looks like it is time for someone to generate the path to remove the depreciation.
>
> Who is up for writing and testing that patch?

I'll send a patch.

--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

keescook at chromium

Aug 3, 2012, 10:16 AM

Post #21 of 21 (107 views)
Permalink

Re: [PATCH v2] futex: mark get_robust_list as deprecated [In reply to]

Right, I'm satisfied with the ptrace_may_access check that was added.
The deprecation was suggested as an additional change. I'm okay
keeping the syscall if someone actually needs it. :)

-Kees

On Fri, Aug 3, 2012 at 5:58 AM, Eric W. Biederman <ebiederm [at] xmission> wrote:
> The permissions on the syscall were fixed them withR ptrace_may_access.
>
> We have identified two legitimate use cases.
>
> It looks like it is time for someone to generate the path to remove the depreciation.
>
> Who is up for writing and testing that patch?
>
> Eric
>

--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads