linux-kernel - Re: Disk geometry from /sys

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:	Thu, 17 Apr 2008 16:49:02 +0200
From:	Seewer Philippe <philippe.seewer@....ch>
To:	Francis Moreau <francis.moro@...il.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Disk geometry from /sys

Hi,

Francis Moreau wrote:
> Hello Seewer,
> 
> On Wed, Apr 16, 2008 at 9:49 AM, Seewer Philippe <philippe.seewer@....ch> wrote:
>>  Correct. Though be really careful which geometry you are requesting:
>>
>>  root@...al:/# sfdisk -g /dev/sda
>>  /dev/sda: 7296 cylinders, 255 heads, 63 sectors/track
>>  root@...al:/# sfdisk -G /dev/sda
>>  /dev/sda: 116280 cylinders, 16 heads, 63 sectors/track
>>
>>  The first one is the kernels idea of a disks geometry which is probably as
>> often correct as it's just plain wrong,
> 
> Sorry but I don't understand, what do you mean ?
Take the example above. A disk with 255 heads? Not impossible but improbable. Where's the value from?

-The physical disks behind the example is an older laptop IDE disk. 'hdparm -I' shows 16 heads and 63 sectors, which is already an approximated value anyway. See Dick Johnson's post about that.

-The module handling the drive is 'ata_piix', the newer Driver from the SATA/PATA tree, which presents all drives (*ATA) to the rest of the system through the scsi sublayer.

-The final "getter" geometry code in the scsi sublayer (scsicam_bios_param in scsicam.c):

        /* if something went wrong, then apparently we have to return
           a geometry with more than 1024 cylinders */
        if (ret || ip[0] > 255 || ip[1] > 63) {
                if ((capacity >> 11) > 65534) {
                        ip[0] = 255;
                        ip[1] = 63;
                } else {
                        ip[0] = 64;
                        ip[1] = 32;
                }

                if (capacity > 65535*63*255)
                        ip[2] = 65535;
                else
                        ip[2] = (unsigned long)capacity / (ip[0] * ip[1]);
        }
Read this as ip[0] is heads, ip[1] is sectors and ip[2] is cylinders. Make sense of course, since C/H/S values don't really matter to scsi anyway. So the default return value for the disks we use today is 255/63 for heads and sectors. A fixed constant which most of the time makes sense and works for most bios and bootloaders, but is wrong in the sense that it doesn't represent the actual values printed on the disks back. 

>>  versus the second one which tries to
>> guess a disks geometry by looking at the current partition table. Which
>> might be just as wrong since its only necessary for bios and/or bootloader.
> 
> But what happens if you want to guess the geometry of a disk with no
> partition table ? You need to trust the kernel guess but from what I understood
> it's just wrong.
Assuming H/S as 255/63 and calculating C from the disks capaticy is quite safe. Except for a few weird use cases like using old OS's and os-installers that still trust the BIOS.
Depending on the type of disks you work with 'hdparm -I' works well too. Otherwise there's always CONFIG_EDD ('BIOS Enhanced Disk Drive calls determine boot disk') which exports BIOS geometry values to sysfs for the current default boot disk.

Hope this helps
Philippe
--
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/