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-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0812181641540.2217-100000@iolanthe.rowland.org>
Date:	Thu, 18 Dec 2008 17:14:44 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jens Axboe <axboe@...nel.dk>
cc:	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Checking a USB drive's capacity

Jens:

As you may know, there are plenty of USB mass-storage devices that
respond incorrectly to READ CAPACITY: They report the total number of
blocks instead of the highest block number.  As a result, the kernel 
thinks the drive has one more sector than it really does.

So far we have dealt with this problem by means of a blacklist, but
this gets more and more unsatisfactory all the time.  We haven't been
able to find any other way to cope, since a few devices are so badly
behaved that they crash hard when you try to access the nonexistent
"last" sector, requiring a replug or power cycle.

My new idea is to keep in the blacklist only those devices which do
crash -- a relatively small number.  Everything else we should be able
to detect safely at runtime, by testing if it's possible to read the
last sector.

The question is, how and where?  The logical place for testing the
capacity is near the end of sd_read_capacity().  However this code runs
before any media accesses have occurred; the drive might not even be
spun up yet.  Not to mention that it seems strange to read the last
sector before reading the first!

It would make more sense to carry out this test after the first sector
has been read.  That's done by the partition management code in the
gendisk layer.  Would near the end of check_partition() be an
appropriate place to make the test?  And could I essentially copy the
code in scsi_ioctl.c:__blk_send_generic()?

Alan Stern

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ