kernel-hardening - Re: [PATCH] time: Remove CONFIG_TIMER

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1702081122190.3536@nanos>
Date: Wed, 8 Feb 2017 11:24:01 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: John Stultz <john.stultz@...aro.org>
cc: Kees Cook <keescook@...omium.org>, Xing Gao <xgao01@...il.wm.edu>, 
    Jessica Frazelle <me@...sfraz.com>, 
    "Eric W. Biederman" <ebiederm@...ssion.com>, 
    Jonathan Corbet <corbet@....net>, Tejun Heo <tj@...nel.org>, 
    Lai Jiangshan <jiangshanlai@...il.com>, Petr Mladek <pmladek@...e.com>, 
    Andrew Morton <akpm@...ux-foundation.org>, Oleg Nesterov <oleg@...hat.com>, 
    Nicolas Iooss <nicolas.iooss_linux@....org>, 
    Nicolas Pitre <nicolas.pitre@...aro.org>, 
    Richard Cochran <richardcochran@...il.com>, 
    "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, 
    Michal Marek <mmarek@...e.com>, Josh Poimboeuf <jpoimboe@...hat.com>, 
    Dmitry Vyukov <dvyukov@...gle.com>, Olof Johansson <olof@...om.net>, 
    Shuah Khan <shuah@...nel.org>, linux-doc@...r.kernel.org, 
    lkml <linux-kernel@...r.kernel.org>, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH] time: Remove CONFIG_TIMER_STATS

On Tue, 7 Feb 2017, John Stultz wrote:
> On Tue, Feb 7, 2017 at 3:40 PM, Kees Cook <keescook@...omium.org> wrote:
> > Currently CONFIG_TIMER_STATS exposes process information across namespaces:
> >
> > kernel/time/timer_list.c print_timer():
> >
> >         SEQ_printf(m, ", %s/%d", tmp, timer->start_pid);
> >
> > /proc/timer_list:
> >
> >  #11: <0000000000000000>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570
> >
> > Given that the tracer can give the same information, this patch entirely
> > removes CONFIG_TIMER_STATS.
> >
> > Suggested-by: Thomas Gleixner <tglx@...utronix.de>
> > Signed-off-by: Kees Cook <keescook@...omium.org>
> 
> I don't have an issue with this, but I worry this would break some
> tooling out there. Should it be marked as deprecated first?
> 
> Or maybe just pulling the band-aid off is the best way?

I think we should just kill it.

No tools can really rely on the behaviour of that file because it depends
on CONFIG_TIMER_STATS and the information available there is just a random
snapshot of queued timers at a given point of time, which is in no way
usefull.

Thanks,

	tglx

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