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: <49970652.7030101@gmail.com>
Date:	Sat, 14 Feb 2009 11:58:42 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
CC:	Mark Lord <liml@....ca>, Sergei Shtylyov <sshtylyov@...mvista.com>,
	Hanno Böck <hanno@...eck.de>,
	linux-kernel@...r.kernel.org, ide <linux-ide@...r.kernel.org>
Subject: Re: Very old IDE hard drive (240 MB) detected as 1.1 TB

Maciej W. Rozycki wrote:
> On Sat, 14 Feb 2009, Mark Lord wrote:
> 
>>>   It has the current capacity in words 57-58 swapped:
>>>
>>> /dev/sdb:
>>> 0c5a 037f 0000 000a 8723 0275 0037 0030
>>> 000a 0000 2020 2020 2020 2020 2020 424d
>>> 3948 4d31 5020 2020 0003 0040 0004 302e
>>> 3336 2020 2020 436f 6e6e 6572 2050 6572
>>> 6970 6865 7261 6c73 2032 3430 4d42 202d
>>> 2043 5033 3032 3534 2020 2020 2020 8010
>>> 0000 0001 0000 0200 0202 0001 037f 000a
>>> 0037 0007 82da 0000 0000 0000 0000 0000
>>>
>>>
>>>   It must be 82da 0007, not 0007 82da.
>>>   IIRC, the IDE core doesn't trust the value reported in these words 
>> ..
>>
>> That's right.  I wrote the IDE code that way
>> *specifically* due to a (different) Conner drive
>> I had here at the time.
> 
>  It happened for some Maxtor drives too.  The reason is the ATA-1 spec was 
> not explicit about how words 57 and 58 were meant to be ordered and some 
> manufacturers interpreted it one and some the other way.  It looks like 
> libata needs to be fixed.

Here's the relevant code, it appears (drivers/ata/libata-core.c at line 
1321):

static u64 ata_id_n_sectors(const u16 *id)
{
	if (ata_id_has_lba(id)) {
		if (ata_id_has_lba48(id))
			return ata_id_u64(id, 100);
		else
			return ata_id_u32(id, 60);
	} else {
		if (ata_id_current_chs_valid(id))
			return ata_id_u32(id, 57);
		else
			return id[1] * id[3] * id[6];
	}
}

It looks like it's getting into the ata_id_current_chs_valid(id) path, 
since all the values that function checks are indeed valid, but the 
values in words 57-58 are not. There seems to be no real reason to use 
those values since the same can be calculated from the reported CHS, so 
you could change that code to:

		if (ata_id_current_chs_valid(id))
			return id[54] * id[55] * id[56];
		else
			return id[1] * id[3] * id[6];

Hanno, would you be able to try building a kernel with a modified 
drivers/ata/libata-core.c as above (in current -git it would be changing 
line 1330) and see if that resolves the problem?
--
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