linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <oss@buserror.net>
To: Kees Cook <keescook@chromium.org>, Jason Yan <yanaijie@huawei.com>
Cc: pmladek@suse.com, rostedt@goodmis.org,
	sergey.senozhatsky@gmail.com, andriy.shevchenko@linux.intel.com,
	linux@rasmusvillemoes.dk, linux-kernel@vger.kernel.org,
	"Tobin C . Harding" <tobin@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Daniel Axtens <dja@axtens.net>
Subject: Re: [PATCH v3 0/6] implement KASLR for powerpc/fsl_booke/64
Date: Wed, 04 Mar 2020 15:11:39 -0600	[thread overview]
Message-ID: <b5854fd867982527c107138d52a61010079d2321.camel@buserror.net> (raw)
In-Reply-To: <202003041022.26AF0178@keescook>

On Wed, 2020-03-04 at 10:34 -0800, Kees Cook wrote:
> On Wed, Mar 04, 2020 at 08:47:07PM +0800, Jason Yan wrote:
> > When I am implementing KASLR for powerpc, Scott Wood argued that format
> > specifier "%p" always hashes the addresses that people do not have a
> > choice to shut it down: https://patchwork.kernel.org/cover/11367547/
> > 
> > It's true that if in a debug environment or security is not concerned,
> > such as KASLR is absent or kptr_restrict = 0,  there is no way to shut
> > the hashing down except changing the code and build the kernel again
> > to use a different format specifier like "%px". And when we want to
> > turn to security environment, the format specifier has to be changed
> > back and rebuild the kernel.
> > 
> > As KASLR is available on most popular platforms and enabled by default,
> > print the raw value of address while KASLR is absent and kptr_restrict
> > is zero. Those who concerns about security must have KASLR enabled or
> > kptr_restrict set properly.
> 
> Sorry, but no: %p censoring is there to stem the flood of endless pointer
> leaks into logs, sysfs, proc, etc. These are used for attacks to build
> reliable kernel memory targets, regardless of KASLR. (KASLR can be
> bypassed with all kinds of sampling methods, side-channels, etc.)
> 
> Linus has rejected past suggestions to provide a flag for it[1],
> wanting %p to stay unconditionally censored.

The frustration is with the inability to set a flag to say, "I'm debugging and
don't care about leaks... in fact I'd like as much information as possible to
leak to me."  Hashed addresses only allow comparison to other hashes which
doesn't help when looking at (or trying to find) data structures in kernel
memory, etc.  I get what Linus is saying about "you can't have nice things
because people won't test the normal config" but it's still annoying. :-P

In any case, this came up now due to a question about what to use when
printing crash dumps.  PowerPC currently prints stack and return addresses
with %lx (in addition to %pS in the latter case) and someone proposed
converting them to %p and/or removing them altogether.  Is there a consensus
on whether crash dumps need to be sanitized of this stuff as well?  It seems
like you'd have the addresses in the register dump as well (please don't take
that away too...).  Maybe crash dumps would be a less problematic place to
make the hashing conditional (i.e. less likely to break something in userspace
that wasn't expecting a hash)?

-Scott



  reply	other threads:[~2020-03-04 21:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-04 12:47 [PATCH] vfsprintf: only hash addresses in security environment Jason Yan
2020-03-04 15:12 ` Andy Shevchenko
2020-03-04 18:34 ` Kees Cook
2020-03-04 21:11   ` Scott Wood [this message]
2020-03-04 22:36     ` [PATCH v3 0/6] implement KASLR for powerpc/fsl_booke/64 Kees Cook
2020-03-05 18:51     ` Linus Torvalds
2020-03-06 18:33       ` Scott Wood
  -- strict thread matches above, loose matches on Subject: below --
2020-02-06  2:58 Jason Yan
2020-02-13  3:00 ` Jason Yan
2020-02-20  3:33   ` Jason Yan
2020-02-26  7:16 ` Daniel Axtens
2020-02-26  8:18   ` Jason Yan
2020-02-26 11:41     ` Daniel Axtens
2020-02-27  1:55       ` Jason Yan
2020-02-28  5:53     ` Scott Wood
2020-02-28  6:47       ` Jason Yan
2020-02-29  4:28         ` Scott Wood
2020-02-29  7:27           ` Jason Yan
2020-02-29 22:54             ` Scott Wood
2020-03-02  2:17               ` Jason Yan
2020-03-02  3:24                 ` Scott Wood
2020-03-02  7:12                   ` Jason Yan
2020-03-02  8:47                     ` Scott Wood
2020-03-02  9:37                       ` Jason Yan
2020-03-04 21:21   ` Scott Wood
2020-03-05  3:22     ` Jason Yan

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=b5854fd867982527c107138d52a61010079d2321.camel@buserror.net \
    --to=oss@buserror.net \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dja@axtens.net \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tobin@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=yanaijie@huawei.com \
    /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;
as well as URLs for NNTP newsgroup(s).