lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 5 Dec 2017 15:33:47 -0800
From:   Linus Torvalds <>
To:     Geert Uytterhoeven <>
Cc:     "Tobin C. Harding" <>,
        "Jason A. Donenfeld" <>,
        "Theodore Ts'o" <>, Kees Cook <>,
        Paolo Bonzini <>,
        Tycho Andersen <>,
        "Roberts, William C" <>,
        Tejun Heo <>,
        Jordan Glover <>,
        Greg KH <>,
        Petr Mladek <>, Joe Perches <>,
        Ian Campbell <>,
        Sergey Senozhatsky <>,
        Catalin Marinas <>,
        Will Deacon <>,
        Steven Rostedt <>,
        Chris Fries <>,
        Dave Weinstein <>,
        Daniel Micay <>,
        Djalal Harouni <>,
        Radim Krčmář <>,
        "" <>,
        Network Development <>,
        David Miller <>,
        Stephen Rothwell <>,
        Andrey Ryabinin <>,
        Alexander Potapenko <>,
        Dmitry Vyukov <>,
        Andrew Morton <>,
        Sergei Shtylyov <>
Subject: Re: [PATCH V11 3/5] printk: hash addresses printed with %p

On Tue, Dec 5, 2017 at 2:57 PM, Geert Uytterhoeven <> wrote:
> Lowest 3 is good enough for all natural types, up to long long.
> We may still receive complaints from people who care about seeing if
> a pointer is cacheline-aligned or not. Fixing that may need up to 7 bits, I'm
> afraid, which is a bit too much to give up.

I really think even the lowest three is a bit too much.

Who really cares? If it's something that is particularly _about_
alignment (ie an alignment trap), maybe just print out those bits

And for everything else? It's purely about getting used to it.

I will just cut-and-paste what I wrote in another thread about the hashing:

  I'm going to require some actual proof of an actual case where it
  mattered that a particular value was hashed.

  Not hand-waving.

  Not "it surprised and confused me" because it looked different. You'll
  get used to it.

  So an actual "this was critical information that mattered for this
  particular bug, and it was missing due to the hashing of this
  particular value and debugging was harder in actual reality due to

  Because the actual example I have seen so far, not only didn't the
  hashing matter AT ALL, most of the _unhashed_ values shouldn't have
  been there either, and were due to arm still printing stuff that
  shouldn't have been printed at all and just made the oops more complex
  and harder to read and report.

This subject is really easy to bike-shed around. Everybody can have an
opinion. I want actual hard data and facts, not opinions.

And if the hashing _really_ is a problem, we'll just change that
particular thing to %px. But it needs actual hard data and real
reasons first, ok?



Powered by blists - more mailing lists