On Fri, Mar 23, 2012 at 3:08 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > Notify get_robust_list users that the syscall is going away. > > Suggested-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> > --- > 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@xxxxxxxxxx> > + > +---------------------------- > + > +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@xxxxxxxxxxxx> > 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-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
