[Dev] usb-manager: set correct usb gadget attributes

Stoppa, Igor igor.stoppa at intel.com
Mon Dec 16 16:31:29 GMT 2013


Hello Krzysztof,

apologies for the late reply, somehow I missed your last mail.
Please find my reply inlined below.


On 27 November 2013 10:57, Krzysztof Opasiak <k.opasiak at samsung.com> wrote:

> Hi Igor,
>
> > -----Original Message-----
> > From: Stoppa, Igor [mailto:igor.stoppa at intel.com]
> > Sent: Friday, November 22, 2013 3:36 PM
> > To: Krzysztof Opasiak
> > Cc: Yang Chengwei; Taeyoung Kim; Krogerus, Heikki;
> > dev at lists.tizen.org; Brad T Peters
> > Subject: Re: [Dev] usb-manager: set correct usb gadget attributes
> >
> > (+Brad)
> >
> > Hi Krzysztof,
> >
> >
> > On 22 November 2013 14:15, Krzysztof Opasiak
> > <k.opasiak at samsung.com> wrote:
> >
> > [snip]
> >
> >       Let me summarize and please correct me if I'm wrong. We have
> > a PC in
> >       host mode and multiple devices with tizen in USB device mode.
> >
> >
> > Typically.
> > However from time to time these devices will be:
> >
> > a) re-flashed to upgrade to a newer tizen build
>
> Flash is done using ttyXACM not usb raw transport directly so there is
> no problem to address each target directly. When you connect two targets
> you will get ttyACM0 and ttyACM1 so the only thing we have to do is to
> write flash tool correctly so you can set which pseudo device you would
> like to use for flashing.
>

that's good - the only constraint here is that the id must be consistent
with both:
1) what is assigned to the device in the factory, if available (but in
commercial devices, it will be available)


2) what is reported by the device when in other modes
but this is really a requirement for the other modes, provided that 1) is
satisfied.


> > b) automatically detached and re-attached to perform some task in a
> > scenario
> > more similar to normal usage (iow no cables)
> >
>
> This scenario could be done using some extension to sdb. Tizen will use
> ConfigFS, we plan to provide API for usb gadgets management. One of the
> benefits of ConfigFS is that we can simply disable and enable gadget in
> a runtime when device is plugged in. So This scenario could be realized
> if sdb will be able to use this API and provide some extension to do
> this. For example sdb could simply execute
>
> $ gt disable sdb_gadget; sleep 5; gt enable sdb_gadget
>

I don't think that's possible.
AFAIK there is no support in the USB standard for electrically disconnect
a gadget device that is connected to a certain port.
Sure, it can be disconnected at logical level, charging can also be refused,
but the gadget will still be aware of the master.

I'm using a USB gadget that acts as real electrical switch [1]



[snip]

> In that case one gets a device with blank SN, but it's such a
> corner case that I would worry
> about it only if it should really happen and affect somebody.
>

I have spoken with my colleagues and they told me that this problem is
> not only in usb. There are other parts of system which needs unique
> numbers. Maybe there should be general solution made for this problem?
> The solution could be similar to this which you described, a special
> partition flashed in factory, but there are some problems. For example
> we should ensure that user will not be able to change the content of
> this partition even with rooted device.
>

Indeed.
Pretty much anything that needs to have a MAC address has similar behaviour
and needs.

The typical hackish solution is to generate a random MAC at first boot and
store
it somewhere.
However usually this won't survive a reflash, because the "somewhere" is
located
on the file system, rather than in a protected area.

Wrt security, I see only 2 options:

a) somehow the system provides some sort of secure storage that can be
accessed
only through a chain of trust that even gaining root cannot spoof.
A bit like DRM, so maybe that infrastructure could be leveraged also for
other purposes.

b) root is demoted and is no different from a somehow privileged user.
But it means that only OEM-signed kernels will be allowed, if the OEM
wishes so.
Btw, this was the security model for the Nokia N9.
And even in case users are allowed to gain full access, it should be
somehow stored
permanently that factory data was overwritten.

Then comes yet another category of data that fits in the same pattern:
calibration data.
Typically this refers to radios.
There might be even legal implications in allowing users to freely change
how the radios
behave.


But all of this would require someone with security background to comment.
I'm not a security expert.


[1] http://www.cleware.net/produkte/p-usbcutter-E.html

-- 
cheers, igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131216/973f8da9/attachment.html>


More information about the Dev mailing list