From: Steven Rostedt <rostedt@goodmis.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: "Tobin C. Harding" <me@tobin.cc>,
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>,
Kees Cook <keescook@chromium.org>, Petr Mladek <pmladek@suse.com>
Subject: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used
Date: Tue, 3 Apr 2018 15:41:02 -0400 [thread overview]
Message-ID: <20180403154102.150b1be0@gandalf.local.home> (raw)
While debugging an issue I needed to see if the pointers were being
processed correctly with trace_printk() and after using "%p" and
triggering my bug and trace output, I was disappointed that all my
pointers were random garbage and didn't produce anything useful for me.
I had to rewrite all the trace_printk()s to use "%lx" instead.
As trace_printk() is not to be used for anything but debugging, and
this is enforced by printing in the dmesg:
**********************************************************
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
** **
** trace_printk() being used. Allocating extra memory. **
** **
** This means that this is a DEBUG kernel and it is **
** unsafe for production use. **
** **
** If you see this message and you are not debugging **
** the kernel, report this immediately to your vendor! **
** **
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
**********************************************************
on boot up if trace_printk() is used (or when a module is loaded that
uses trace_printk()), we can safely assume that the use of
trace_printk() is not going to be accidentally added to production code
(and if it is, they should be whacked with an overcooked spaghetti
noodle).
A new bool is added called "trace_debug" and if it is set, then %p will
not be hashed.
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.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
diff --git a/include/linux/printk.h b/include/linux/printk.h
index e9b603ee9953..7ef6c31d874a 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 bool trace_debug;
extern asmlinkage void dump_stack(void) __cold;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 0f47e653ffd8..cb58cd4ee3a7 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 */
+ trace_debug = true;
+ 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..425644ceedcb 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;
+bool trace_debug __read_mostly;
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 (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);
}
next reply other threads:[~2018-04-03 19:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-03 19:41 Steven Rostedt [this message]
2018-04-03 20:07 ` Kees Cook
2018-04-03 21:06 ` Steven Rostedt
2018-04-03 21:43 ` Tobin C. Harding
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=20180403154102.150b1be0@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=David.Laight@ACULAB.COM \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=me@tobin.cc \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®