All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tobin C. Harding" <me@tobin.cc>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: kernel-hardening@lists.openwall.com, linux-kernel@vger.kernel.org
Subject: [kernel-hardening] Re: [PATCH v7] printk: hash addresses printed with %p
Date: Thu, 26 Oct 2017 09:14:11 +1100	[thread overview]
Message-ID: <20171025221411.GA12341@eros> (raw)
In-Reply-To: <CAKwiHFgUEfXJ3TRzwD4dm6TFVM6ffdzb-riMAhnobnZrjD0ySw@mail.gmail.com>

On Wed, Oct 25, 2017 at 09:02:34PM +0200, Rasmus Villemoes wrote:
> On 25 October 2017 at 01:57, Tobin C. Harding <me@tobin.cc> wrote:
> > On Tue, Oct 24, 2017 at 09:25:20PM +0200, Rasmus Villemoes wrote:
> >>
> >> I haven't followed the discussion too closely, but has it been
> >> considered to exempt NULL from hashing?
> >
> [snip]
> >
> > The code in question is;
> >
> > static noinline_for_stack
> > char *pointer(const char *fmt, char *buf, char *end, void *ptr,
> >               struct printf_spec spec)
> > {
> >         const int default_width = 2 * sizeof(void *);
> >
> >         if (!ptr && *fmt != 'K') {
> >                 /*
> >                  * Print (null) with the same width as a pointer so it makes
> >                  * tabular output look nice.
> >                  */
> >                 if (spec.field_width == -1)
> >                         spec.field_width = default_width;
> >                 return string(buf, end, "(null)", spec);
> >         }
> 
> Ah, yes, I should have re-read the current code before commenting. So
> we're effectively already exempting NULL due to this early handling.
> Good, let's leave that.
> 
> Regarding the tabular output: Ignore it, it's completely irrelevant to
> the hardening efforts (good work, btw), and probably completely
> irrelevant period. If anything I'd say the comment and the attempted
> alignment should just be killed.

Righto, I'm happy with that. Will add to next version.

> > This check and print "(null)" is at the wrong level of abstraction. If we want tabular output to be
> > correct for _all_ pointer specifiers then spec.field_width (for NULL) should be set to match whatever
> > field_width is used in the associated output function. Removing the NULL check above would require
> > NULL checks adding to at least;
> >
> > resource_string()
> > bitmap_list_string()
> > bitmap_string()
> > mac_address_string()
> > ip4_addr_string()
> > ip4_addr_string_sa()
> > ip6_addr_string_sa()
> > uuid_string()
> > netdev_bits()
> > address_val()
> > dentry_name()
> > bdev_name()
> > ptr_to_id()
> 
> No, please don't. The NULL check makes perfect sense early in
> pointer(), because many of these handlers would dereference the
> pointer, and while it's probably a bug to pass NULL to say %pD, it's
> obviously better to print (null) than crash. Adding NULL checks to
> each of these is error-prone and lots of bloat for no real value
> (consider that many of these can produce lots of variants of output,
> and e.g. dotted-decimal ip addresses don't even have a well-defined
> width at all).
> 
> > My question is [snip] is it too trivial to matter?
> 
> Yes.

thanks,
Tobin.

WARNING: multiple messages have this Message-ID (diff)
From: "Tobin C. Harding" <me@tobin.cc>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: kernel-hardening@lists.openwall.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7] printk: hash addresses printed with %p
Date: Thu, 26 Oct 2017 09:14:11 +1100	[thread overview]
Message-ID: <20171025221411.GA12341@eros> (raw)
In-Reply-To: <CAKwiHFgUEfXJ3TRzwD4dm6TFVM6ffdzb-riMAhnobnZrjD0ySw@mail.gmail.com>

On Wed, Oct 25, 2017 at 09:02:34PM +0200, Rasmus Villemoes wrote:
> On 25 October 2017 at 01:57, Tobin C. Harding <me@tobin.cc> wrote:
> > On Tue, Oct 24, 2017 at 09:25:20PM +0200, Rasmus Villemoes wrote:
> >>
> >> I haven't followed the discussion too closely, but has it been
> >> considered to exempt NULL from hashing?
> >
> [snip]
> >
> > The code in question is;
> >
> > static noinline_for_stack
> > char *pointer(const char *fmt, char *buf, char *end, void *ptr,
> >               struct printf_spec spec)
> > {
> >         const int default_width = 2 * sizeof(void *);
> >
> >         if (!ptr && *fmt != 'K') {
> >                 /*
> >                  * Print (null) with the same width as a pointer so it makes
> >                  * tabular output look nice.
> >                  */
> >                 if (spec.field_width == -1)
> >                         spec.field_width = default_width;
> >                 return string(buf, end, "(null)", spec);
> >         }
> 
> Ah, yes, I should have re-read the current code before commenting. So
> we're effectively already exempting NULL due to this early handling.
> Good, let's leave that.
> 
> Regarding the tabular output: Ignore it, it's completely irrelevant to
> the hardening efforts (good work, btw), and probably completely
> irrelevant period. If anything I'd say the comment and the attempted
> alignment should just be killed.

Righto, I'm happy with that. Will add to next version.

> > This check and print "(null)" is at the wrong level of abstraction. If we want tabular output to be
> > correct for _all_ pointer specifiers then spec.field_width (for NULL) should be set to match whatever
> > field_width is used in the associated output function. Removing the NULL check above would require
> > NULL checks adding to at least;
> >
> > resource_string()
> > bitmap_list_string()
> > bitmap_string()
> > mac_address_string()
> > ip4_addr_string()
> > ip4_addr_string_sa()
> > ip6_addr_string_sa()
> > uuid_string()
> > netdev_bits()
> > address_val()
> > dentry_name()
> > bdev_name()
> > ptr_to_id()
> 
> No, please don't. The NULL check makes perfect sense early in
> pointer(), because many of these handlers would dereference the
> pointer, and while it's probably a bug to pass NULL to say %pD, it's
> obviously better to print (null) than crash. Adding NULL checks to
> each of these is error-prone and lots of bloat for no real value
> (consider that many of these can produce lots of variants of output,
> and e.g. dotted-decimal ip addresses don't even have a well-defined
> width at all).
> 
> > My question is [snip] is it too trivial to matter?
> 
> Yes.

thanks,
Tobin.

  reply	other threads:[~2017-10-25 22:14 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-23 22:33 [kernel-hardening] [PATCH v7] printk: hash addresses printed with %p Tobin C. Harding
2017-10-23 22:33 ` Tobin C. Harding
2017-10-23 23:00 ` [kernel-hardening] " Jason A. Donenfeld
2017-10-23 23:00   ` Jason A. Donenfeld
2017-10-24  0:31   ` [kernel-hardening] " Tobin C. Harding
2017-10-24  0:31     ` Tobin C. Harding
2017-10-24 11:25     ` [kernel-hardening] " Jason A. Donenfeld
2017-10-24 11:25       ` Jason A. Donenfeld
2017-10-24 20:45       ` [kernel-hardening] " Tobin C. Harding
2017-10-24 20:45         ` Tobin C. Harding
2017-10-25  3:49       ` [kernel-hardening] " Tobin C. Harding
2017-10-25  3:49         ` Tobin C. Harding
2017-10-30 20:22         ` [kernel-hardening] " Steven Rostedt
2017-10-30 20:22           ` Steven Rostedt
2017-10-30 21:24           ` [kernel-hardening] " Tobin C. Harding
2017-10-30 21:24             ` Tobin C. Harding
2017-10-31 14:22           ` [kernel-hardening] " Jason A. Donenfeld
2017-10-31 14:22             ` Jason A. Donenfeld
2017-10-24 19:25 ` [kernel-hardening] " Rasmus Villemoes
2017-10-24 21:52   ` Tobin C. Harding
2017-10-24 23:57   ` Tobin C. Harding
2017-10-25 19:02     ` Rasmus Villemoes
2017-10-25 19:02       ` Rasmus Villemoes
2017-10-25 22:14       ` Tobin C. Harding [this message]
2017-10-25 22:14         ` Tobin C. Harding
2017-10-25 16:22 ` [kernel-hardening] [lkp-robot] [printk] 7f7c60e066: BUG:KASAN:slab-out-of-bounds kernel test robot
2017-10-25 16:22   ` kernel test robot
2017-10-25 16:22   ` kernel test robot
2017-10-31  0:14   ` [kernel-hardening] " Kees Cook
2017-10-31  0:14     ` Kees Cook
2017-10-31  0:14     ` Kees Cook
2017-10-30  9:57     ` [kernel-hardening] " Ye Xiaolong
2017-10-30  9:57       ` Ye Xiaolong
2017-10-30  9:57       ` Ye Xiaolong
2017-10-31  2:39     ` [kernel-hardening] " Tobin C. Harding
2017-10-31  2:39       ` Tobin C. Harding
2017-10-31  2:47       ` [kernel-hardening] " Kees Cook
2017-10-31  2:47         ` Kees Cook
2017-10-31  2:47         ` Kees Cook
  -- strict thread matches above, loose matches on Subject: below --
2017-10-25  4:00 [kernel-hardening] Re: [PATCH v7] printk: hash addresses printed with %p Jason A. Donenfeld
2017-10-25 10:05 ` Tobin C. Harding
2017-10-25 22:27 ` Tobin C. Harding
2017-10-25 22:59   ` Jason A. Donenfeld
2017-10-25 23:11     ` Tobin C. Harding
2017-10-26  7:00     ` Greg KH
2017-10-26  9:10       ` Tobin C. Harding

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=20171025221411.GA12341@eros \
    --to=me@tobin.cc \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    /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.