linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Timur Tabi <timur@kernel.org>, Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	willy@infradead.org, akpm@linux-foundation.org,
	torvalds@linux-foundation.org, roman.fietze@magna.com,
	keescook@chromium.org, john.ogness@linutronix.de,
	akinobu.mita@gmail.com
Subject: Re: [PATCH][RESEND] lib/vsprintf: make-printk-non-secret printks all addresses as unhashed
Date: Fri, 5 Feb 2021 11:59:06 +0100	[thread overview]
Message-ID: <3baace45-38af-a59b-c376-9a4c39a17b2d@suse.cz> (raw)
In-Reply-To: <20210202213633.755469-1-timur@kernel.org>

On 2/2/21 10:36 PM, Timur Tabi wrote:
> If the make-printk-non-secret command-line parameter is set, then
> printk("%p") will print addresses as unhashed.  This is useful for
> debugging purposes.
> 
> A large warning message is displayed if this option is enabled,
> because unhashed addresses, while useful for debugging, exposes
> kernel addresses which can be a security risk.
> 
> Signed-off-by: Timur Tabi <timur@kernel.org>

Thanks a lot. Should this also affect %pK though? IIUC, there's currently no way
to achieve non-mangled %pK in all cases, even with the most permissive
kptr_restrict=1 setting:
- in IRQ, there's "pK-error" instead
- in a context of non-CAP_SYSLOG process, nulls are printed

Yes, neither should matter if %pK were only used for prints that generate
content of some kind of /proc file read by a CAP_SYSLOG process, but that
doesn't seem to be the case and there are %pK used for printing to dmesg too...

> ---
>  lib/vsprintf.c | 34 ++++++++++++++++++++++++++++++++--
>  1 file changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 3b53c73580c5..b9f87084afb0 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -2090,6 +2090,30 @@ 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 */
> +static bool debug_never_hash_pointers __ro_after_init;
> +
> +static int __init debug_never_hash_pointers_enable(char *str)
> +{
> +	debug_never_hash_pointers = true;
> +	pr_warn("**********************************************************\n");
> +	pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
> +	pr_warn("**                                                      **\n");
> +	pr_warn("** All pointers that are printed to the console will    **\n");
> +	pr_warn("** be printed as unhashed.                              **\n");
> +	pr_warn("**                                                      **\n");
> +	pr_warn("** Kernel memory addresses are exposed, which may       **\n");
> +	pr_warn("** compromise security on 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 vendor!  **\n");
> +	pr_warn("**                                                      **\n");
> +	pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
> +	pr_warn("**********************************************************\n");
> +	return 0;
> +}
> +early_param("make-printk-non-secret", debug_never_hash_pointers_enable);
> +
>  /*
>   * Show a '%p' thing.  A kernel extension is that the '%p' is followed
>   * by an extra set of alphanumeric characters that are extended format
> @@ -2297,8 +2321,14 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
>  		}
>  	}
>  
> -	/* default is to _not_ leak addresses, hash before printing */
> -	return ptr_to_id(buf, end, ptr, spec);
> +	/*
> +	 * default is to _not_ leak addresses, so hash before printing, unless
> +	 * make-printk-non-secret is specified on the command line.
> +	 */
> +	if (unlikely(debug_never_hash_pointers))
> +		return pointer_string(buf, end, ptr, spec);
> +	else
> +		return ptr_to_id(buf, end, ptr, spec);
>  }
>  
>  /*
> 



  parent reply	other threads:[~2021-02-05 10:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-02 21:36 Timur Tabi
2021-02-03  3:24 ` Sergey Senozhatsky
2021-02-03  3:30   ` Randy Dunlap
2021-02-03  9:54 ` Petr Mladek
2021-02-03 13:31   ` Petr Mladek
2021-02-03 18:58     ` Timur Tabi
2021-02-03 19:30       ` Andy Shevchenko
2021-02-03 20:02       ` Kees Cook
2021-02-03 20:25         ` Steven Rostedt
2021-02-03 20:35           ` Kees Cook
2021-02-03 20:47             ` Steven Rostedt
2021-02-03 21:56               ` Timur Tabi
2021-02-03 22:38                 ` Steven Rostedt
2021-02-04  9:36               ` Petr Mladek
2021-02-05 10:59 ` Vlastimil Babka [this message]
2021-02-05 18:25   ` Timur Tabi
2021-02-10  0:24     ` Kees Cook
2021-02-09 21:59 ` Marco Elver
2021-02-09 22:15   ` Timur Tabi

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=3baace45-38af-a59b-c376-9a4c39a17b2d@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=john.ogness@linutronix.de \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox