[systemd-devel] WebUSB

[Lars Knudsen]

On Tue, Jan 10, 2017 at 7:08 PM, Dan Williams <dcbw at redhat.com> wrote:

> On Tue, 2017-01-10 at 18:33 +0100, Greg KH wrote:
> > On Tue, Jan 10, 2017 at 06:23:13PM +0100, Lars Knudsen wrote:
> > >
> > >
> > > On Jan 10, 2017 18:19, "Greg KH" <greg at kroah.com> wrote:
> > >
> > >     On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote:
> > >     > I figured that made most sense :)
> > >     >
> > >     > Still, it would be good if we could have a rule to not grab
> > > the CDC
> > >     interface
> > >     > part if the device includes WebUSB functionality.
> > >
> > >     What exactly do you mean by "grab"?
> > >
> > > MM probing :)
> >
> > Probe should be fine, right?  Are you really thinking that MM needs
> > to
> > go "oh look, a cdc device, let's go look at all of the raw interfaces
> > to
> > ensure it really isn't a webusb device as well before I touch it!"
> >
> > That way lies madness...
> >
> > What's wrong with touching it?  The kernel already did, why would
> > userspace care?
>
> And we're quite happy to keep blacklisting specific VID/PID combos we
> know are not modems. Another possible solution is to greylist devices
> that happen to have webusb descriptors, such that they won't get auto-
> probed, but could be probed on-demand via D-Bus.  But I'd rather that
> happen via udev rules than MM trying to walk USB device attributes and
> parsing webusb descriptors.
>

Actually, that sounds like a very good compromise.  I remember my own
struggles 3-4 years ago when I had to get a device working properly on
ChromeOS and Ubuntu, where the firmware had to handle that the first ~16
seconds it would *sometimes* get sent strange AT commands (the probing) all
while the system thought it could already start speaking with the device
over e.g. chrome.serial.  Eventually you (modemmanager) were kind enough to
get our VID/PID listed and ChromeOS was quick to pick it up (~5-6 months to
get in stable) and ubuntu so kind to upgrade to the version of modemmanager
including our blacklisting approx 2.5 years later (sigh) ;)

If greylisting prevents auto-probing, I think it would be very valuable for
devices with a WebUSB header because those will in most cases (as I see
them used) be industrial things (like my current medical company employer)
or IoT devices.  And waiting ~16 seconds for a fallback to USB Serial where
WebUSB is not available (or for other reasons not chosen), can be a real
pain.

I agree that a solid udev rule would be a good way forward (I'll look into
greylisting and see if I can come up with something that covers) and maybe
this could also be the place to do the user space access (or not - I'll try
to come back with something.

thanks for all the input.  Maybe Kenneth, Reilly or some working on USB
related things in Intel have something to add?


>
> Dan
>
> > >     > The likelihood of a modem+WebUSB combo is so small that it
> > > must fall
> > >     > in the category where potential rare exotic devices combining
> > > it must
> > >     > be whitelisted and the rest be left alone.
> > >
> > >     I think you misunderstand just how crazy firmware authors can
> > > be.  I'm
> > >     sure we will see those types of devices in the wild.
> > >
> > > ...But realistically how many? Bothering 99.9% to support the
> > > special case
> > > seems less logical than just finding the 0.1% and whitelisting it
> > > (if needed)
> >
> > That's the joy of writing an operating system for all devices on the
> > planet, those 0.1% can be a lot of devices :)
> >
> > Anyway, I don't think there's much to do here just yet, let's wait
> > and
> > see just how bad these webusb devices end up looking like...
> >
> > thanks,
> >
> > greg k-h
> > _______________________________________________
> > ModemManager-devel mailing list
> > ModemManager-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20170110/59b8b9d4/attachment-0001.html>