On Sun, Dec 10, 2017 at 12:39:11PM -0800, Linus Torvalds wrote:
> On Sun, Dec 10, 2017 at 4:52 AM, Andy Shevchenko
> <andy.shevche...@gmail.com> wrote:
> >>
> >>> Perhaps it should have printed a fixed, non-zero value for non-zero
> >>> pointers.
> >>
> >> I must leave this to the people who have a dog in that contest. ;-)
> >
> > Since there is an ongoing discussion with security people near to %pK
> > and alike, I added Kees and Linus to Cc list.
> >
> > The proposed change can be done easily, though I have no knowledge
> > about possible implications.
>
> I'd rather make %pK act more like %p than have gratuitous differences.
>
> I also think %pK is kind of pointless in general. It has not been a
> big success, and the whole "root or not" is kind of nasty anyway. Root
> in a container? Things like that.
>
> So I think that if people worry about leaking pointers, they should
> primarily go for:
>
> - just use %p and now get the hashed value
>
> - if the hashed value is pointless, ask yourself whether the pointer
> itself is important. Maybe it should be removed?
>
> - as a last option, if you really think the true pointer value is
> important, why is root so special, and maybe you should use %px and
> make sure you have proper sensible permissions.
>
> ..and %pK just isn't really the answer in any of those cases.
My main use case is comparing pointer values directly, for example,
in the console log against those in event-trace output. So if those
are hashed the same way, I wouldn't even notice.
I very rarely need to compute offsets, but I thought that the low-order
bits were excluded from the hash to make this work straightforwardly in
the common case. Of course, computing offsets could be a problem for
larger structures, by my reaction to that would be to make the kernel
do the offset computation for me as needed.
So it looks like I should drop the three patches in my tree that convert
%p to %pK.
Any objections?
Thanx, Paul
