Please Cc me on any replies, since I'm not subscribe to this list.
Thanks.
I'm evaluating MXI Security's Stealth MXP 4 GB hardware encrypted USB
thumb drive w/biometric reader. It works okay in Windows and MacOS X,
but fails under Linux with data corruption issues. Here is the output
of lsusb:
Bus 004 Device 007: ID 124c:3200
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x124c
idProduct 0x3200
bcdDevice 4.13
iManufacturer 1 MXI
iProduct 2 StealthMXP 2.0
iSerial 3 0AF50726E00D01F8
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
MaxPower 300mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 255
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
When plugged in, the device presents one LUN which is an unencrypted,
read-only 80 MB drive containg Windows software and documentation for
managing the device. After authenticating to the device by swiping
your finger across the biometric reader a second LUN appears, which is
the encrypted store. Here LUN 01 is the read-only plaintext store,
and LUN 00 is the read-write encrypted store:
#cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: MXI Model: PRIVATE Rev:
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 00 Lun: 01
Vendor: MXI Model: READ ONLY Rev:
Type: Direct-Access ANSI SCSI revision: 02
First LUN 01 shows up as /dev/sdb and gets mounted on /media/ACCESS SW
by gnome-volume-manager. After authenticating, LUN 00 shows up as
/dev/sda, which is initially formatted as FAT32. I started noticing
corruption on files larger than 64k, so I tried to see what would
happen by writing defined patterns to the raw disk device and reading
the data back.
Here is an example hexdump of the results of trying to zero the
beginning of the device:
#dd if=/dev/zero of=/dev/sda bs=64k count=100
#dd if=/dev/sda bs=64k count=100|hexdump|less
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0010000 e8e0 c5b5 f582 d838 9dfa 20f4 0d37 579b
0010010 0000 0000 0000 0000 0000 0000 0000 0000
*
0031000 e8e0 c5b5 f582 d838 9dfa 20f4 0d37 579b
0031010 0000 0000 0000 0000 0000 0000 0000 0000
*
0050000 e8e0 c5b5 f582 d838 9dfa 20f4 0d37 579b
0050010 0000 0000 0000 0000 0000 0000 0000 0000
*
0070000 e8e0 c5b5 f582 d838 9dfa 20f4 0d37 579b
0070010 0000 0000 0000 0000 0000 0000 0000 0000
*
0090000 e8e0 c5b5 f582 d838 9dfa 20f4 0d37 579b
0090010 0000 0000 0000 0000 0000 0000 0000 0000
*
00b0000 e8e0 c5b5 f582 d838 9dfa 20f4 0d37 579b
00b0010 0000 0000 0000 0000 0000 0000 0000 0000
*
00d0000 e8e0 c5b5 f582 d838 9dfa 20f4 0d37 579b
00d0010 0000 0000 0000 0000 0000 0000 0000 0000
*
As you can see, the corruption is always 16 bytes in size and the
offsets seem to fall into a pattern of sorts. The corruption is also
always the same for this specific data set. When I looked at the
corruption in the files that I stored when it was formatted as FAT32,
it was different and seems to be data-dependent.
If I repeat the exact test on MacOS X, there is no problem. All zeros
get written and read back from the device. If I then take the zeroed
USB stick back to a Linux system and try to read it, I get corrupted
data. So the corruption definately happens when Linux reads from the
device.
If I re-zero the device on Linux and take it back to MacOS X, the same
corruption shows up there. So the corruption also happens when Linux
writes to the device.
I'm using Fedora 5 and 6 for my testing, and I've tried several
kernels including 2.6.18-1.2798.fc6, 2.6.20-1.2962.fc6, and
2.6.22.2-42.fc6. My colleague has also tried Slackware Linux with
kernel 2.6.21.5, and the problem appears there as well.
Does anyone know what might be going on here? It seems there is a bug
somewhere in Linux usb-storage. I've never head issues with regular
USB sticks before--could the problem here be due to the multiple LUNs?
Please Cc me on any replies, since I'm not subscribe to this list.
Thanks.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
