[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ca1371e2-8df3-3e28-b5d6-b4bc0fbe6b70@kernel.org>
Date: Wed, 10 Feb 2021 11:27:45 -0600
From: Timur Tabi <timur@...nel.org>
To: Petr Mladek <pmladek@...e.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Vlastimil Babka <vbabka@...e.cz>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Matthew Wilcox <willy@...radead.org>,
akpm@...ux-foundation.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
roman.fietze@...na.com, Kees Cook <keescook@...omium.org>,
John Ogness <john.ogness@...utronix.de>,
akinobu.mita@...il.com, glider@...gle.com,
Andrey Konovalov <andreyknvl@...gle.com>,
Marco Elver <elver@...gle.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH 3/3] lib/vsprintf: make-printk-non-secret printks all
addresses as unhashed
On 2/10/21 7:41 AM, Petr Mladek wrote:
>
> The option causes that vsprintf() will not hash pointers. Yes, it is
> primary used by printk(). But it is used also in some other
> interfaces, especially trace_printk(), seq_buf() API. The naked
> pointers might appear more or less anywhere, including procfs,
> sysfs, debugfs.
Fair point. Shouldn't calls to seq_buf_printf() (and any printk usage
that always exists in the context of a user-space process) use %pK anyway?
Hmmm.... maybe vsprintf() should automatically replace %p with %pK if it
detects a user-space context?
> IMHO, we should fix this. The long discussion was about how to make
> this option safe. Users should be aware that it is not only about
> the kernel log.
Agreed.
> I suggest to rename the parameter "debug_never_hash_pointer" and use
> the same name for the parameter and the variable.
Will do.
> We also should make the warning more generic. I suggest to replace the
> first paragraph with something like:
>
> pr_warn("** The hashing of printed pointers has been disabled **\n");
> pr_warn("** for debugging purposes. **\n");
>
> Feel free to use a better wording. I am not a native speaker.
You could have fooled me.
> Of course, also kernel-parameters.txt has to be updated accordingly.
Ok.
Powered by blists - more mailing lists