[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+g6nbDz+gjAxZTSf1004J=naAf7b9dPTE0q8+7UtXCLw@mail.gmail.com>
Date: Tue, 3 Apr 2018 13:07:58 -0700
From: Kees Cook <keescook@...omium.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
"Tobin C. Harding" <me@...in.cc>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
David Laight <David.Laight@...lab.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Petr Mladek <pmladek@...e.com>
Subject: Re: [RFC][PATCH] tracing, printk: Force no hashing when
trace_printk() is used
On Tue, Apr 3, 2018 at 12:41 PM, Steven Rostedt <rostedt@...dmis.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
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
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists