linux-kernel - Re: usb hdd problems with 2.6.27.2

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]

Date:	Mon, 27 Oct 2008 17:26:17 +0100
From:	"Kay Sievers" <kay.sievers@...y.org>
To:	"Boaz Harrosh" <bharrosh@...asas.com>
Cc:	dgilbert@...erlog.com, "Alan Stern" <stern@...land.harvard.edu>,
	"Luciano Rocha" <luciano@...otux.com>,
	"James Bottomley" <James.Bottomley@...senpartnership.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux-Kernel <linux-kernel@...r.kernel.org>,
	"USB list" <linux-usb@...r.kernel.org>,
	"SCSI development list" <linux-scsi@...r.kernel.org>
Subject: Re: usb hdd problems with 2.6.27.2

On Mon, Oct 27, 2008 at 16:08, Boaz Harrosh <bharrosh@...asas.com> wrote:
> Douglas Gilbert wrote:
>>
>> Since the READ CAPACITY "off by one" error is so common,
>> perhaps drivers such as usb-storage could have a hook to
>> do a pseudo READ CAPACITY. Then if the capacity value
>> looked odd (in both senses) the driver could do an IO to
>> the suspect block and if that failed decrement the capacity
>> value passed back to the mid level.
>> Put another way, why don't these defective devices trip up
>> another OS?
>>
>
> Window$ never reads the last sector unless it is actually written
> to. I had such a device it got stuck when I wrote to the
> last sector.
>
>> BTW a single disk in RAID 0 (seen on a HP E200 controller)
>> has a shortened capacity value seen in the midlevel on the
>> corresponding logical drive. That missing chunk is probably
>> where the RAID controller puts its control information.
>> Anyway, playing with the capacity value returned by READ
>> CAPACITY certainly has a precedent.
>>
>>> Later on the system tries to read the contents of what it thinks is the
>>> last sector:
>>
>> I know that happens but it seems strange that upper levels
>> are reading a block that has never been written to. Read ahead?
>>
>
> That would be udev or hald, I can't remember which. It is a special Linux
> fixture. ;)

It's vol_id from udev. To auto-detect raid setups, LVM, MD metadata, ...

Such devices carry their magic sequence at the "end" of the device,
usually the last sector or a few sectors before the last sector. The
"last" sector is obviously determined by the capacity the device
reports.

There is no way around looking at all block devices' last sector on a
Linux box, as long as people expect auto-setup, auto-mounting,
anything that is not put in /etc/fstab to work, as long as any "meta
device" format puts a magic number at the end of the device.

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