linux-kernel - Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

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:   Thu, 25 Aug 2016 16:55:21 -0400
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Bjørn Mork <bjorn@...k.no>
Cc:     Rafał Miłecki <zajec5@...il.com>,
        Richard Purdie <rpurdie@...ys.net>,
        Jacek Anaszewski <j.anaszewski@...sung.com>,
        Felipe Balbi <balbi@...nel.org>,
        Peter Chen <hzpeterchen@...il.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        Rafał Miłecki <rafal@...ecki.pl>,
        Jonathan Corbet <corbet@....net>,
        Ezequiel Garcia <ezequiel@...guardiasur.com.ar>,
        Matthias Brugger <mbrugger@...e.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Stephan Linz <linz@...pro.net>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:LED SUBSYSTEM" <linux-leds@...r.kernel.org>
Subject: Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

On Thu, Aug 25, 2016 at 08:39:24PM +0200, Bjørn Mork wrote:
> Greg KH <gregkh@...uxfoundation.org> writes:
> > On Thu, Aug 25, 2016 at 07:14:52AM +0200, Rafał Miłecki wrote:
> >>
> >> Good question. I would like to extend this USB port trigger in the
> >> future by reacting to USB activity. This involves playing with URBs
> >> and I believe that at that point it'd be getting too much USB specific
> >> to /rule them all/.
> >
> > Oh that's never going to work, sorry.  USB "activity" happens deep in
> > USB host controller hardware, not up at the kernel level at all.  It's
> > just too fast, and would take up too much CPU to do it otherwise.  Heck,
> > even old UHCI 1.1 USB controllers did this.
> >
> > USB "activity" happens all the time, look at a USB bus analyzer if you
> > want to see what goes on.  Teasing out what is "real data" and what is
> > just "normal bus activity" is impossible at the kernel level,
> 
> OK, I am going to play stupid again: Does this mean that usbmon is
> impossible?

Hah, nice try :)

I guess when I think "USB activity" I think about the lower layers of
frames and acks and naks on the bus.  But maybe because I have just
recently been doing a lot of work down at the EHCI frame timing layer
for some strange hardware...

But you are right, if all you care about is the data that the host sees,
then yes, you could do something like usbmon to "tickle" a led if you
want to.

Odds are, someone's already done this for a raspberry pi :)

thanks,

greg k-h