All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Petr Mladek <pmladek@suse.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Marco Elver <elver@google.com>, Timur Tabi <timur@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	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 14:37:19 +0100	[thread overview]
Message-ID: <8893ff08-1e50-316c-f632-cd37be1690d5@suse.cz> (raw)
In-Reply-To: <YD49x/UGUq6MSE39@alley>

On 3/2/21 2:29 PM, Petr Mladek wrote:
> On Tue 2021-03-02 13:51:35, Geert Uytterhoeven wrote:
>> > > > +
>> > > > +       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"?
> 
> This was the deal. The configure option is a no-go, see below and also
> https://lore.kernel.org/r/CAHk-=wgaK4cz=K-JB4p-KPXBV73m9bja2w1W1Lr3iu8+NEPk7A@mail.gmail.com

I think it's a no-go only when enabling such option equals to "no_hash_pointers"
being always passed. What Geert suggests is that you need both
CONFIG_DEBUG_KERNEL *and* no_hash_pointers and that's different.

>> > 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
>> 
>> I guess the people who do care about kernel size do know to disable
>> CONFIG_DEBUG_KERNEL, so it would help them.
>> The everything-but-the-kitchen-sink distro people don't care about kernel
>> size anyway.
> 
> The problem with the configure option is not about size. The problem is
> that there would be many kernels in the wild with this option enabled.
> People would install them without knowing that they are less secure.

Same as above.

> Distros would need to provide both kernels. Well, they already do.
> But it might be worse. Some distros might even want to enable it
> by default.
> 
> Also many bugs might be debugged without this option. Some bugs
> are hard to reproduce and might be visible only on production
> systems. It should be possible to enable this only when really
> needed and the user must be aware of the risk.

So this is basically a kernel tinyfication issue, right? Is that still pursued
today? Are there better config options suitable for this than CONFIG_DEBUG_KERNEL?

>> > Would placing the strings into an __initconst array help?
>> 
>> That would indeed help to reduce run-time memory consumption.
> 
> Sure. We could do this. Do you want to send a patch, please?
> 
>> It would not solve the raw kernel size increase.
> 
> I see. Well, the compression should be pretty efficient
> for a text (with many spaces).
> 
> Best Regards,
> Petr
> 


  reply	other threads:[~2021-03-02 16:23 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
2021-03-02 12:51       ` Geert Uytterhoeven
2021-03-02 13:29         ` Petr Mladek
2021-03-02 13:37           ` Vlastimil Babka [this message]
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=8893ff08-1e50-316c-f632-cd37be1690d5@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=elver@google.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=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.