linux-kernel - Re: [PATCH v2] vsprintf: don't obfuscate NULL and error pointers

lists.openwall.net		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] [day] [month] [year] [list]

Message-ID: <CAOi1vP9p4dC1HfzmgP_GR=p4p8LWfxPQTGfHf3QaCFp6vF-V2Q@mail.gmail.com>
Date:   Mon, 13 Apr 2020 11:24:30 +0200
From:   Ilya Dryomov <idryomov@...il.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Petr Mladek <pmladek@...e.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Kees Cook <keescook@...omium.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        "Tobin C . Harding" <me@...in.cc>
Subject: Re: [PATCH v2] vsprintf: don't obfuscate NULL and error pointers

On Fri, Apr 10, 2020 at 11:40 AM David Laight <David.Laight@...lab.com> wrote:
>
> From: Linus Torvalds
> > Sent: 08 April 2020 17:23
> > On Wed, Apr 8, 2020 at 8:08 AM Andy Shevchenko
> > <andy.shevchenko@...il.com> wrote:
> > >
> > > For the better understanding the current state of affairs I suggest to respin
> > > new version after rc1 and we will see again.
>
> If the hash of a pointer ends up being one of the values that
> wouldn't be hashed, perhaps it should be hashed again.
> That will remove any possible confusion.

Hi David,

That seems sensible, but out of scope of this patch IMO.

My goal was to fix a 5.2 regression for NULL pointers.  I tacked on
IS_ERR pointers because they aren't actual addresses either and hashing
them makes zero sense.  Although simple to implement, I'm afraid that
introducing additional rounds of hashing would drag this patch further
(it's already got bogged down in the test suite structure discussion).

Thanks,

                Ilya