Re: gadget file storage with variable maxpacket

On Tuesday 08 January 2008, ilya wrote:

> > > association, etc.
> >
> > In the security/session sense?  Again, I'd expect such stuff
> > to be transparent to the gadget drivers.  Experience Has Shown
> > that applications trying to manage authentication are as a rule
> > bug-ridden security holes that only accomplish difficulty-of-use
> > rather than improving security.  Maybe it could be made visible
> > to drivers after the basic infrastructure works smoothly though.
> 
> so in order for a new WUSB device to connect with a host it first needs
> to be "associated" with it; it is a one-time procedure that says that
> in the future this specific device can connect to this specific host.
> 
> so far there are two standard mechanism for this [technically three
> but i don't know how many controllers will implement near-field association]
> i think the numeric association can be kept inside the driver controller;
> it is based on the deiffie-hellman key exchange and requires tedious
> calculations, but on the other hand it would be nice if it was implemented
> inside gadget so in the future any controller driver can support it without
> much work.

What I'd actually like is to have this packaged so that it can
work with wired links too.  The issue isn't calculation ... but
how to securely store the keys.  Remember that the security of
the system depends on security of those keys.  Imagine that they
are managed in separate crypto hardware module, and they physically
can't leave that module.   Keys are then completely inaccessible to
any gadget driver.  That will give the right model for software.

That applies equally on the host side, of course.


> cable association can definitely be implemented on the gadget side
> because it acts as separate wired device. i have already written a generic
> cable association gadget. the only problem i am facing is that the
> CBAF gadget needs to be aware of the main gadget [g_file_storage,
> g_zero, ...] since it needs to provide to the host with some info, such the
> device's friendly name, what language it uses, etc.

I've not looked at this stuff in a long time, but I'd expect that
it should be possible to let the standard EP0 interfaces to the
gadget driver handle all that stuff ... and just punt unrecognized
control requests (that happen to be for association management) to
the relevant module.


> now, i think this is the most complex part... what if we have a controller
> that supports both wired and wireless and maybe can even run two
> separate device simultaneously, one on each side.

Presenting two separate gadgets would be a bit of a stretch.  :)


> what if when i plugin 
> my device i want to do cable association but also run the main gadget
> wiredly [by advertising two interfaces and so forth, this is very common
> among the devices i've seen so far] what if i want to run g_file_storage via
> WUSB and simultaneously run g_zero on wired? i think the execution
> of multiple gadgets can wait but at a minimum there should be mechanism
> of advertising CBAF along with whatever gadget is running on wired and
> have one aware of the other.

To save myself the effort of re-reading specs (and other folk on this
list from reading them the first time) ... is the ability to support
associations exposed in the config descriptors?

If so, then the gadget drivers would need updating to support this
scheme.  And then they could reasonably just delegate unrecognized
setup calls to a library module which manages associations.


> > > i think a lot of these things could be handled by the controller driver,
> > > but there are a lot of other stuff that could be standardized and handled
> > > by the "gadget" client side.
> > >
> > > what does david brownell think about this?
> >
> > I'm open to proposals.
> 
> soon i am going to post my list of what i think is crucial to make the
> Gadget API wireless and what would be nice to have and we can go
> from there.

OK, looking forward to see that proposal.

- Dave


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel