From: "Tobin C. Harding" <me@tobin.cc>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Kees Cook <keescook@chromium.org>,
LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Laight <David.Laight@aculab.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Petr Mladek <pmladek@suse.com>
Subject: Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used
Date: Wed, 4 Apr 2018 07:43:49 +1000 [thread overview]
Message-ID: <20180403214349.GF781@eros> (raw)
In-Reply-To: <20180403170612.7b11fc41@gandalf.local.home>
On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote:
> On Tue, 3 Apr 2018 13:07:58 -0700
> Kees Cook <keescook@chromium.org> wrote:
>
> > On Tue, Apr 3, 2018 at 12:41 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > > Both trace_debug is set and kptr_restrict is set to zero in the same
> > > code that produces the above banner. This will allow trace_printk() to
> > > not be affected by security code, as trace_printk() should never be run
> > > on a machine that needs security of this kind.
> >
> > While I think it'd be nice to have a boot-time knob for this (a debate
> > that was unsuccessful in earlier threads), I remain skeptical of
> > having a _runtime_ knob for this, as then it becomes a target (and
> > yes, there are plenty of targets, but why add another).
> >
> > If this was __ro_after_init, maybe that'd be nicer. CONFIG_TRACING=y
>
> Well, then of course this would need a check to keep modules from
> setting it. But I think I know of a nice alternative.
>
>
> > is used everywhere, so this is really just the whole knob debate over
> > again. Instead, I've been following Linus's distillation of %p usage
> > in the kernel:
> >
> > http://lkml.kernel.org/r/CA+55aFwQEd_d40g4mUCSsVRZzrFPUJt74vc6PPpb675hYNXcKw@mail.gmail.com
>
> Remember, this isn't a printk() that hangs around for production. I was
> debugging code that modified pointers, and I wanted to make sure that
> the pointer arithmetic was correct (it wasn't), and randomizing the
> output made my prints useless.
>
> If you are concerned about attack surface, I could make it a bit more
> difficult to tweak by malicious software. What about the patch below?
> It would be much more difficult to modify this knob from an attack
> vector.
>
> -- Steve
>
> diff --git a/include/linux/printk.h b/include/linux/printk.h
> index e9b603ee9953..b624493b3991 100644
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -278,6 +278,7 @@ static inline void printk_safe_flush_on_panic(void)
> #endif
>
> extern int kptr_restrict;
> +extern struct static_key trace_debug;
>
> extern asmlinkage void dump_stack(void) __cold;
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 0f47e653ffd8..6c151d00848b 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -2864,6 +2864,10 @@ void trace_printk_init_buffers(void)
>
> buffers_allocated = 1;
>
> + /* This is a debug kernel, allow pointers to be shown */
> + static_key_enable(&trace_debug);
> + kptr_restrict = 0;
> +
> /*
> * trace_printk_init_buffers() can be called by modules.
> * If that happens, then we need to start cmdline recording
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 89f8a4a4b770..c3d8eafecb39 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1345,6 +1345,7 @@ char *uuid_string(char *buf, char *end, const u8 *addr,
> }
>
> int kptr_restrict __read_mostly;
> +struct static_key trace_debug = STATIC_KEY_INIT_FALSE;
>
> static noinline_for_stack
> char *restricted_pointer(char *buf, char *end, const void *ptr,
> @@ -1962,6 +1963,10 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
> return pointer_string(buf, end, ptr, spec);
> }
>
> + /* When the kernel is in debugging mode, show all pointers */
> + if (static_key_false(&trace_debug))
> + return restricted_pointer(buf, end, ptr, spec);
> +
> /* default is to _not_ leak addresses, hash before printing */
> return ptr_to_id(buf, end, ptr, spec);
> }
This uses the deprecated API Steve (I only know because I went to read
Documentation/static-keys.txt after seeing this patch).
Hope this helps,
Tobin.
next prev parent reply other threads:[~2018-04-03 21:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-03 19:41 [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used Steven Rostedt
2018-04-03 20:07 ` Kees Cook
2018-04-03 21:06 ` Steven Rostedt
2018-04-03 21:43 ` Tobin C. Harding [this message]
2018-04-03 22:59 ` Steven Rostedt
2018-04-04 7:49 ` Peter Zijlstra
2018-04-04 13:36 ` Steven Rostedt
2018-04-04 16:27 ` Kees Cook
2018-04-04 16:52 ` Steven Rostedt
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=20180403214349.GF781@eros \
--to=me@tobin.cc \
--cc=David.Laight@aculab.com \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.