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  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 <>
To:     "Tobin C. Harding" <>, Kees Cook <>
Cc:     LKML <>
Subject: Re: [GIT PULL] hash addresses printed with %p

On Wed, Nov 29, 2017 at 11:22 AM, Linus Torvalds
<> 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?


Powered by blists - more mailing lists