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]
Message-ID: <Pine.LNX.4.44L0.0812182326100.31272-100000@netrider.rowland.org>
Date:	Thu, 18 Dec 2008 23:33:09 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	Jens Axboe <axboe@...nel.dk>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Checking a USB drive's capacity

On Thu, 18 Dec 2008, Alan Cox wrote:

> > spun up yet.  Not to mention that it seems strange to read the last
> > sector before reading the first!
> 
> The SCSI CD code deals with this by spotting the error is close to the
> end and of particular types then interpreting it and adjusting the volume
> size. This is done because the size value for a CD-R/RW is imprecise.

Although it may be okay for CDs, I suspect that approach won't work for 
disks.

For one thing, this would cause the volume size to change after the 
partition table had been read and interpreted, which doesn't seem like 
a good idea.

For another, it would cause the location of the "last" sector to change 
in mid-flight, which might well cause problems for programs like vol_id 
and hald_probe_storage -- they need to read the last sector to 
determine if the volume is part of a RAID array.

Now maybe these objections won't matter; the code in each case might be 
resilient enough to handle such changes.  Do you think it could work?

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