linux-kernel - Re: usb/core: warning in usb_create_ep_devs/sysfs_create_dir

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:   Tue, 13 Dec 2016 15:09:37 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Dmitry Vyukov <dvyukov@...gle.com>
cc:     syzkaller <syzkaller@...glegroups.com>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        USB list <linux-usb@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Kostya Serebryany <kcc@...gle.com>
Subject: Re: usb/core: warning in usb_create_ep_devs/sysfs_create_dir_ns

On Tue, 13 Dec 2016, Dmitry Vyukov wrote:

> On Tue, Dec 13, 2016 at 7:38 PM, Alan Stern <stern@...land.harvard.edu> wrote:
> > On Tue, 13 Dec 2016, Dmitry Vyukov wrote:
> >
> >> On Tue, Dec 13, 2016 at 4:52 PM, Alan Stern <stern@...land.harvard.edu> wrote:
> >> > On Tue, 13 Dec 2016, Dmitry Vyukov wrote:
> >> >
> >> >> >> >  If it is
> >> >> >> > not a bug in kernel source code, then it must not produce a WARNING.
> >> >> >
> >> >> > What about a memory allocation failure?  The memory management part of
> >> >> > the kernel produces a WARNING message if an allocation fails and the
> >> >> > caller did not specify __GFP_NOWARN.
> >> >> >
> >> >> > There is no way for a driver to guarantee that a memory allocation
> >> >> > request will succeed -- failure is always an option.  But obviously
> >> >> > memory allocation failures are not bugs in the kernel.
> >> >> >
> >> >> > Are you saying that mm/page_alloc.c:warn_alloc() should produce
> >> >> > something other than a WARNING?
> >> >>
> >> >>
> >> >> The main thing I am saying is that we absolutely need a way for a
> >> >> human or a computer program to be able to determine if there is
> >> >> anything wrong with kernel or not.
> >> > Doesn't it also produce a WARNING under other circumstances?
> >>
> >> No.
> >>
> >> OOM is not a WARNING and is easily distinguishable from BUG/WARNING.
> >
> >> Memory allocator does not print WARNINGs on allocation failures.
> >
> > Do you count dev_warn the same as WARN or WARN_ON?  What about dev_WARN
> > or pr_warn() or printk(KERN_WARNING...)?  Maybe we're not talking about
> > the same messages.
> >
> > The USB subsystem has got tons of dev_warn() and dev_err() calls.
> > Relatively few (if any) of them are for kernel bugs.
> 
> 
> I grep for "WARNING:". It is not possible to understand what function
> printed messages on console.
> Here are my current regexps:
> https://github.com/google/syzkaller/blob/master/report/report.go#L29

Ah, okay.

So the take-home message is that we should use WARN* or dev_WARN or
related functions only when reporting an actual kernel bug, whereas in
other circumstances we should avoid mentioning "WARNING" or "BUG" in
log output.  In addition, memory allocations where the size is given by
the user (and not limited) should always use the __GFP_NOWARN flag.

I can audit the parts of the USB stack that I'm familiar with for these 
things.  Anything else?  What about "ERROR"?  Your regexps don't appear 
to search for that.

Alan Stern