linux-kernel - Re: USB gadget with drivers "on board"

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:	Wed, 28 Apr 2010 10:46:12 +0200
From:	Michał Nazarewicz <m.nazarewicz@...sung.com>
To:	Josua Dietze <digidietze@...isberghof.de>,
	Alan Stern <stern@...land.harvard.edu>
Cc:	Daniel Mack <daniel@...aq.de>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB list <linux-usb@...r.kernel.org>,
	Kyungmin Park <kyungmin.park@...sung.com>
Subject: Re: USB gadget with drivers "on board"

>> On Mon, 26 Apr 2010, Josua Dietze wrote:
>>> These are the notorious mode switching devices. In Windows, they
>>> obviously install a special storage driver doing one specific action
>>> on each following plugging.
>>> This action - some storage or control command - will "flip" the
>>> device, making it "disconnect" and returning as a completely different
>>> composite device.
>>>
>>> Storage commands used for this procedure range from "SCSI rezero" over
>>> "passthrough" to "SCSI eject", or involve vendor specific stuff.

> Alan Stern schrieb:
>> I was going to say the same thing.  For ease of use, I recommend using
>> a "SCSI eject" to trigger the mode change.  That way, Linux users who
>> don't have the usb-modeswitch program installed can get the same effect
>> by running eject.

On Mon, 26 Apr 2010 22:14:54 +0200, Josua Dietze <digidietze@...isberghof.de> wrote:

> Important for the Linux handling is that "mode 1" is clearly
> distinguishable from "mode 2", either by using a different product ID
> or by setting a different class for the device or interface 0 (will
> most likely be "8" for the install mode).

So it will be enough to change the USB device class for the zeroth
interface for udev to recognise the mass storage to be ejected?  Note
that I will use mass storage in the second mode as well.

Also, I think that it might be a good idea to make some "standardised"
mechanism for all such devices so that a generic udev code could be
written.  Adding things to the descriptors may be difficult in a way,
but maybe adding "[NoCD]" to the interface name would be enough.

-- 
Best regards,                                        _     _
| Humble Liege of Serenely Enlightened Majesty of  o' \,=./ `o
| Computer Science,  Michał "mina86" Nazarewicz       (o o)
+----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/