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

Krzysztof Opasiak k.opasiak at samsung.com
Wed Dec 18 09:58:41 GMT 2013


+ Tomasz Swierczek

Dear Security team,
could you support us in discussion about the topic from the bottom of
message?


Hi Igor,

> -----Original Message-----
> From: Stoppa, Igor [mailto:igor.stoppa at intel.com]
> Sent: Monday, December 16, 2013 5:31 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
> 
> 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.

But why would you like to use the ID for flashing?

In my opinion USB topology is better to discover which USB device we are
talking to. Let's assume that you have 3 different targets. You would
like to flash them all but each with different image. It's better to
know which cable is ttyACM1, ttyACM2 etc. than know the 3 long id's of
each device. The topology could be constant. You can have some stickers
on USB connectors and connect "connector 1" to target XYZ and then you
are sure that you are flashing this particular device. If you would like
to do that same with ID's you should compare the longs targets ID's
instead of simply connecting the device to correct connector.

> 
> 
> 
> 	> 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]
> 

Such electrical switch is not necessary. In Tizen reference Kernel we
have ConfigFS and we will use it for gadget composition. There is a
"file" called UDC. So doing simply:

$ echo "" > UDC

Disables gadget and

$ echo "udc-name" > UDC

Enables gadget. Those commands are enough to do support your scenario.
For host it's similar to physical detachment of device.


-------------------------TOPIC FOR SECURITY TEAM----------------



Please read the previous discussion below and share your opinion about
storing device specific data like SN's, MAC address and some calibration
data.

 
> 
> 	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.

I'm also and that's why I pleased security Team to join the discussion.

-- 
BR's

Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics






More information about the Dev mailing list