Re: [PATCH tip/core/rcu 02/20] torture: Prepare scripting for shift from %p to %pK

[Paul E. McKenney]

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.shevchenko@xxxxxxxxx> 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