[kernel-hardening] Re: [PATCH v5] printk: hash addresses printed with %p

[Joe Perches <joe@perches.com>]

On Thu, 2017-10-19 at 10:45 +1100, Tobin C. Harding wrote:
> On Wed, Oct 18, 2017 at 03:31:16PM -0700, Kees Cook wrote:
> > On Wed, Oct 18, 2017 at 2:30 PM, Tobin C. Harding <me@tobin.cc> wrote:
> > > Currently there are many places in the kernel where addresses are being
> > > printed using an unadorned %p. Kernel pointers should be printed using
> > > %pK allowing some control via the kptr_restrict sysctl. Exposing addresses
> > > gives attackers sensitive information about the kernel layout in memory.
> > 
> > Is it intended for %pK to be covered by the hash as well? (When a
> > disallowed user is looking at %pK output, like kallsyms, the same hash
> > is seen for all values, rather than just zero -- I assume since the
> > value hashed is zero.)
> 
> Good catch, thanks. Have fixed for v6, will wait 24 hours before submitting.
> 
> > > +       spec.field_width = 2 + 2 * sizeof(unsigned int); /* 0x + hex */
> > > +       spec.flags = SPECIAL | SMALL | ZEROPAD;
> > 
> > I don't think this should have SPECIAL. We end up changing things like
> > kallsyms (which didn't have 0x before) and printing with double 0x's:

> While on the topic, have you an opinion on whether SMALL is good here. My first thought was that
> capitals _kind_of_ showed that it was an ID not an address, later contemplation made me think this
> may only have meaning to myself from working on the patch so better to leave it SMALL like original.

Perhaps using start/stop indicators could highlight this hashing.

Perhaps output using #hash_ptr#

by adding something like
#define HASHED	128		/* Output hashed ptr with # prefix and postfix */
after #define SPECIAL

but also perhaps adding to the column width would break
hex parsers of seq_ output

> Any thoughts appreciated.

2¢