linux-kernel - Re: USB disconnect, address 6

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] [day] [month] [year] [list]

Date:	Tue, 07 Apr 2009 17:11:09 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Jon Grant <jg@...k.org>
CC:	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org
Subject: Re: USB disconnect, address 6

Jon Grant wrote:
> 2009/4/6 Greg KH <greg@...ah.com>:
>> On Mon, Apr 06, 2009 at 11:11:55AM +0200, Jon Grant wrote:
> [..]
>>> The idea was that the disconnect could give more information.
>>> Otherwise it's necessary to go hunting back up the log to track down
>>> which USB device was the one disconnected (which works fine, but isn't
>>> ideal for time consumed doing this regularly).
>>
>> As you yanked the device out, don't you know which one it was?
> 
> I do get devices disappear without me disconnecting them, various
> different PCs, and laptops.

Try FireWire then. ;-)

> [..]
>>> Apr  5 18:56:58 data-laptop kernel: usb 5-1: USB disconnect, address 6
>>> (Samsung  Mighty Drive)
>>>
>>> Would this not be clearer?
>>
>> That might be nice, but note that the kernel doesn't even know the
>> strings after a device is gone, as it had to read them from the device
>> :)
> 
> Yeah, would need to cache the names, perhaps you don't want to bloat
> the kernel that way.

"Samsung Mighty Drives" is some information which the Linux SCSI layer
obtained from the device's response to the SCSI INQUIRY command.  The
USB layer sits beneath the SCSI layer and passes SCSI commands and
responses through without looking at them... most of the time, at least.
I haven't checked whether usb-storage examines SCSI inquiry buffers
these days.  Typically we don't want to duplicate high-level
functionality into lower layers, hence knowledge of SCSI commands and
responses is mostly kept out of Linux' SCSI transports layer (e.g.
usb-storage).

The INQUIRY reposne however /is/ already cached by Linux.  It's in
<scsi/scsi_device.h>'s struct scsi_device { .inquiry_len; .inquiry; }.
Furthermore, .vendor; .model; .rev; point into respective byte fields in
the inquiry response buffer.  Here is the code line which produces the
initial dmesg line with the vendor/model/rev strings:
http://lxr.linux.no/linux+v2.6.29/drivers/scsi/scsi_scan.c#L847

However, it would be slightly difficult for the USB stack to access this
information.  It's in a (grand-grand-?)child of the actual USB device
representations with which the USB stack deals directly.  To implement
what you want, the USB stack would have to check whether
(grand-grand-?)children of type scsi_device were ever created, then peek
into its device data (with some SCSI-specific knowledge).  Or the
usb-storage driver would have to watch for scsi_device creations by the
upper layers (i.e. by layers outside of the USB stack) and copy their
data into whichever USB parent device for possible later use.

Not quite cleanly doable.

Plus, Greg was right when he said that the strings in these INQUIRY
responses are generally not unique and sometimes pure garbage.
-- 
Stefan Richter
-=====-==--= -=-- --===
http://arcgraph.de/sr/
--
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/