2017-11-02 13:44:32

by Roberts, William C

[permalink] [raw]
Subject: RE: [PATCH V8 0/2] printk: hash addresses printed with %p



> -----Original Message-----
> From: Tobin C. Harding [mailto:[email protected]]
> Sent: Thursday, November 2, 2017 3:15 AM
> To: Sergey Senozhatsky <[email protected]>
> Cc: Sergey Senozhatsky <[email protected]>; kernel-
> [email protected]; Jason A. Donenfeld <[email protected]>;
> Theodore Ts'o <[email protected]>; Linus Torvalds <torvalds@linux-
> foundation.org>; Kees Cook <[email protected]>; Paolo Bonzini
> <[email protected]>; Tycho Andersen <[email protected]>; Roberts,
> William C <[email protected]>; Tejun Heo <[email protected]>; Jordan
> Glover <[email protected]>; Greg KH
> <[email protected]>; Petr Mladek <[email protected]>; Joe
> Perches <[email protected]>; Ian Campbell <[email protected]>; Catalin Marinas
> <[email protected]>; Will Deacon <[email protected]>; Steven
> Rostedt <[email protected]>; Chris Fries <[email protected]>; Dave
> Weinstein <[email protected]>; Daniel Micay <[email protected]>; Djalal
> Harouni <[email protected]>; [email protected]
> Subject: Re: [PATCH V8 0/2] printk: hash addresses printed with %p
>
> On Thu, Nov 02, 2017 at 05:23:44PM +0900, Sergey Senozhatsky wrote:
> > On (11/01/17 10:35), Tobin C. Harding wrote:
> > [..]
> > > Yes. The question has been raised will we be here again in 6 years
> > > time trying to fix all the uses of %x. And there are already 29K
> > > uses of %[xX] in tree, which of these are leaking addresses? This is why Linus'
> > > has commented that really effort should be directed at finding the
> > > leaks as they happen (in procfs, sysfs, dmesg) instead of fixing
> > > this in the code.
> >
> > got it. thanks.
> >
> > > So far I haven't been able to come up with any meaningful way to do
> > > this on 32 bit machines. There is a patch adding a script to catch
> > > leaks on 64 bit machines in flight.
> >
> > who is expected to run that script?
>
> If one person runs it and finds one leaking address, I'd say it wast worth writing. If
> a bunch of people with different set ups run it and we find a bunch of leaking
> addresses, WIN!

I wonder if the 0 day testing robot could run it....

>
> Your comment did give me the idea of adding some output to the command
> offering an email address to send suspicious output for those who do not wish to
> investigate it further. I can put my email address if there is not a better option.
>
> > BTW, can BPF/eBPF printk addresses?
>
> I know absolutely zero about BPF/eBPF. I guess now is a good time to learn.
>
> > > This patch needs to be a small part of a continued effort to stop
> > > the leaks if we want to have any hope of stopping them.
> > >
> > > If you have any suggestions on dealing with %x please do say. We
> > > have code changes, compiler warnings, and checkpatch - none of which
> > > immediately seem great.
> >
> > hm... just a huge pile of if's
> >
> > if (is_vmalloc_addr(addr))
> > do_hashing(addr);
> > else if (__module_address(addr))
> > do_hashing(addr);
> > else if (is_kernel(addr) || is_kernel_inittext(addr))
> > ...
> >
> > but that's going to be really messy and "iffy".
>
> This is the only suggestion we have so far.
>
> thanks,
> Tobin.

From 1582948968587560161@xxx Thu Nov 02 10:16:15 +0000 2017
X-GM-THRID: 1582089505245226476
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread