linux-kernel - Re: [GIT PULL] hash addresses printed with %p

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 29 Nov 2017 11:39:23 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Tobin C. Harding" <me@...in.cc>, Kees Cook <keescook@...omium.org>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] hash addresses printed with %p

On Wed, Nov 29, 2017 at 11:22 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> What I didn't realize until after pulling this and testing, is that it
> completely breaks '%pK'.
>
> We've marked various sensitive pointers with %pK, but that is now
> _less_ secure than %p is, since it doesn't do the hashing because of
> how you refactored the %pK code out of 'pointer()' into its own
> function.
>
> So now %pK ends up using the plain "number()" function. Reading
> through the series I hadn't noticed that the refactoring ended up
> messing with that.
>
> I'll fix it up somehow.

I ended up just doing this:

            case 'K':
    +               if (!kptr_restrict)
    +                       break;
                    return restricted_pointer(buf, end, ptr, spec);

which basically says that "if kptr_restrict isn't set, %pK is the same as %p".

Now, I feel that we should probably get rid of 'restricted_pointer()'
entirely, since now the regular '%p' is arguably safer than '%pK' is,
but I also didn't want to mess with the case that I have never used
and that most distros don't seem to set.

Alternatively, we might make the 'K' behavior of clearing the pointer
be in addition to the other flags, so that you could do '%pxK' and get
the old %pK behavior. But since I am not a huge fan of %pK to begin
with, I can't find it in myself to care too much.

So I'll leave that for Kees & co to decide on. Comments?

                  Linus