All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Timur Tabi <timur@kernel.org>, Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Matthew Wilcox <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	roman.fietze@magna.com, Kees Cook <keescook@chromium.org>,
	John Ogness <john.ogness@linutronix.de>,
	Akinobu Mita <akinobu.mita@gmail.com>,
	Alexander Potapenko <glider@google.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Pavel Machek <pavel@ucw.cz>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>
Subject: Re: [PATCH 3/3] [v4] lib/vsprintf: no_hash_pointers prints all addresses as unhashed
Date: Tue, 2 Mar 2021 13:45:07 +0100	[thread overview]
Message-ID: <CANpmjNNm-4s16_KQ1_NqFN4XOESJh4_=33LHQzt+p4V0Cy=Xzw@mail.gmail.com> (raw)
In-Reply-To: <CAMuHMdULKZCJevVJcp7TxzLdWLjsQPhE8hqxhnztNi9bjT_cEw@mail.gmail.com>

On Tue, 2 Mar 2021 at 12:51, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Timur,
>
> On Sun, Feb 14, 2021 at 5:17 PM Timur Tabi <timur@kernel.org> wrote:
> > If the no_hash_pointers command line parameter is set, then
> > printk("%p") will print pointers as unhashed, which is useful for
> > debugging purposes.  This change applies to any function that uses
> > vsprintf, such as print_hex_dump() and seq_buf_printf().
> >
> > A large warning message is displayed if this option is enabled.
> > Unhashed pointers expose kernel addresses, which can be a security
> > risk.
> >
> > Also update test_printf to skip the hashed pointer tests if the
> > command-line option is set.
> >
> > Signed-off-by: Timur Tabi <timur@kernel.org>
>
> Thanks for your patch, which is now commit 5ead723a20e0447b
> ("lib/vsprintf: no_hash_pointers prints all addresses as unhashed") in
> v5.12-rc1.
>
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -2090,6 +2090,32 @@ char *fwnode_string(char *buf, char *end, struct fwnode_handle *fwnode,
> >         return widen_string(buf, buf - buf_start, end, spec);
> >  }
> >
> > +/* Disable pointer hashing if requested */
> > +bool no_hash_pointers __ro_after_init;
> > +EXPORT_SYMBOL_GPL(no_hash_pointers);
> > +
> > +static int __init no_hash_pointers_enable(char *str)
> > +{
> > +       no_hash_pointers = true;
> > +
> > +       pr_warn("**********************************************************\n");
> > +       pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
> > +       pr_warn("**                                                      **\n");
> > +       pr_warn("** This system shows unhashed kernel memory addresses   **\n");
> > +       pr_warn("** via the console, logs, and other interfaces. This    **\n");
> > +       pr_warn("** might reduce the security of your system.            **\n");
> > +       pr_warn("**                                                      **\n");
> > +       pr_warn("** If you see this message and you are not debugging    **\n");
> > +       pr_warn("** the kernel, report this immediately to your system   **\n");
> > +       pr_warn("** administrator!                                       **\n");
> > +       pr_warn("**                                                      **\n");
> > +       pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
> > +       pr_warn("**********************************************************\n");
> > +
> > +       return 0;
> > +}
> > +early_param("no_hash_pointers", no_hash_pointers_enable);
>
> While bloat-o-meter is not smart enough to notice the real size impact,
> this does add more than 500 bytes of string data to the kernel.
> Do we really need such a large message?
> Perhaps the whole no_hash_pointers machinery should be protected by
> "#ifdef CONFIG_DEBUG_KERNEL"?

We recently stumbled across this, and it appears an increasing number
of production kernels enable CONFIG_DEBUG_KERNEL [1], so it likely
isn't the solution (we tried to use CONFIG_DEBUG_KERNEL in similar
way, and it wasn't reliable). Having no_hash_pointers frees us of
having to rely on CONFIG_DEBUG_KERNEL. (Perhaps somebody else will
comment, but I believe there were strong objections to making the
pointer hashing dependent on more Kconfig options.)

[1] https://lkml.kernel.org/r/20210223082043.1972742-1-elver@google.com

Would placing the strings into an __initconst array help?

Thanks,
-- Marco

  reply	other threads:[~2021-03-02 15:09 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-14 16:13 [PATCH 0/3][v4] add support for never printing hashed addresses Timur Tabi
2021-02-14 16:13 ` [PATCH 1/3] [v4] lib: use KSTM_MODULE_GLOBALS macro in kselftest drivers Timur Tabi
2021-02-14 16:13 ` [PATCH 2/3] [v4] kselftest: add support for skipped tests Timur Tabi
2021-02-14 16:13 ` [PATCH 3/3] [v4] lib/vsprintf: no_hash_pointers prints all addresses as unhashed Timur Tabi
2021-03-02 11:51   ` Geert Uytterhoeven
2021-03-02 12:45     ` Marco Elver [this message]
2021-03-02 12:51       ` Geert Uytterhoeven
2021-03-02 13:29         ` Petr Mladek
2021-03-02 13:37           ` Vlastimil Babka
2021-03-02 13:49             ` Geert Uytterhoeven
2021-03-02 14:08               ` Steven Rostedt
2021-03-02 14:26                 ` Marco Elver
2021-03-02 14:35                   ` Matthew Wilcox
2021-03-02 14:40                     ` Marco Elver
2021-03-02 14:55                       ` Geert Uytterhoeven
2021-03-02 14:57                         ` Marco Elver
2021-03-02 14:28                 ` Geert Uytterhoeven
2021-03-02 15:16                   ` Rasmus Villemoes
2021-03-02 15:29                   ` Andy Shevchenko
2021-03-02 17:53               ` Petr Mladek
2021-09-11  2:25   ` Xiaoming Ni
2021-09-11  2:39     ` Tetsuo Handa
2021-02-14 16:18 ` [PATCH 0/3][v4] add support for never printing hashed addresses Timur Tabi
2021-02-15 11:08   ` Petr Mladek

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='CANpmjNNm-4s16_KQ1_NqFN4XOESJh4_=33LHQzt+p4V0Cy=Xzw@mail.gmail.com' \
    --to=elver@google.com \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=geert@linux-m68k.org \
    --cc=glider@google.com \
    --cc=john.ogness@linutronix.de \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=pavel@ucw.cz \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=pmladek@suse.com \
    --cc=roman.fietze@magna.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=timur@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.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.