linux-kernel - VFS issue with hardware-encrypted usb devices

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

Date:	Wed, 05 Jan 2011 10:57:31 +0100
From:	Guillaume Rousse <guillomovitch@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: VFS issue with hardware-encrypted usb devices

Hello.

I'm currently playing with hardware-encrypted Imation defender USB
devices, which are USB keys/drives, using password and/or fingerprint
sensors for unlocking content:
http://www.imation.com/en-us/Imation-Products/

The main issue is that they are automatically mounted under gnome (and I
guess all other modern desktop) before being unlocked, and the VFS
doesn't likes the behind-the-scene changes very much.

Here the syslog trace when plugging (the normal partition is seen as a
CD-ROM, the encrypted one as a standard removal drive):
Jan  3 15:14:07 beria kernel: : usb 2-1: new high speed USB device using
ehci_hcd and address 8
Jan  3 15:14:08 beria kernel: : usb 2-1: New USB device found,
idVendor=0718, idProduct=0682
Jan  3 15:14:08 beria kernel: : usb 2-1: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Jan  3 15:14:08 beria kernel: : usb 2-1: Product: Defender F200
Jan  3 15:14:08 beria kernel: : usb 2-1: Manufacturer: Imation
Jan  3 15:14:08 beria kernel: : usb 2-1: SerialNumber: F5121031F003008E
Jan  3 15:14:08 beria kernel: : scsi10 : usb-storage 2-1:1.0
Jan  3 15:14:09 beria kernel: : scsi 10:0:0:0: CD-ROM
Defender F200 Application 0001 PQ: 0 ANSI: 2
Jan  3 15:14:09 beria kernel: : sr0: scsi-1 drive
Jan  3 15:14:09 beria kernel: : sr 10:0:0:0: Attached scsi generic sg1
type 5
Jan  3 15:14:09 beria kernel: : scsi 10:0:0:1: Direct-Access
Defender F200 Private     0001 PQ: 0 ANSI: 2
Jan  3 15:14:09 beria kernel: : sd 10:0:0:1: Attached scsi generic sg2
type 0
Jan  3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] 18434 512-byte
logical blocks: (9.43 MB/9.00 MiB)
Jan  3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Write Protect is off
Jan  3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Assuming drive cache:
write through
Jan  3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Assuming drive cache:
write through
Jan  3 15:14:09 beria kernel: : sdb:
Jan  3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Assuming drive cache:
write through
Jan  3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Attached SCSI
removable disk

Then unlocking is performed, by sweeping fingerprint sensor, and the
hardware change, triggering issues:
Jan  3 15:14:21 beria kernel: : VFS: busy inodes on changed media or
resized disk sdb
Jan  3 15:14:21 beria kernel: : sd 10:0:0:1: [sdb] 3393536 512-byte
logical blocks: (1.73 GB/1.61 GiB)
Jan  3 15:14:21 beria kernel: : sd 10:0:0:1: [sdb] Assuming drive cache:
write through

Jan  3 15:14:40 beria kernel: : FAT: Filesystem error (dev sdb)
Jan  3 15:14:40 beria kernel: : fat_get_cluster: invalid cluster chain
(i_pos 262)
Jan  3 15:14:40 beria kernel: : FAT: Filesystem has been set read-only
Jan  3 15:14:40 beria kernel: : FAT: Filesystem error (dev sdb)

If I'm quick enough at jumping on sensor to unlock at mount time,
everything works fine, meaning the real issue is changing partition
status when already mounted.

I don't know how this issue should be properly handled. Should the VFS
be aware than some kind of exotic hardware are able to perform this kind
of tricks ? Should the automounter be able to manage those kind of
device by not mouting them automatically, at least until they reach
proper state ?

Forgive me if it's not the right place to discuss the issue, but I
couldn't find a better one for VFS issues.
-- 
BOFH excuse #31:

cellular telephone interference
--
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/