linux-kernel - Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0 drives and a monolithic kernel configuration)

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:	Sun, 28 Oct 2012 04:17:00 +0100
From:	Wallak <wallak@...e.fr>
To:	Chris Friesen <chris.friesen@...band.com>
CC:	linux-kernel@...r.kernel.org, ak@...ux.intel.com
Subject: Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0
 drives and a monolithic kernel configuration)

I've found where this issue come from. This behavior was introduced with 
the commit: 0cc15d03bcccdf95e2bd82e094e6064e61b54207.The description is 
available below. Removing this patch fix the drive order.


Best Regards,
Wallak.


commit 0cc15d03bcccdf95e2bd82e094e6064e61b54207
Author: Andi Kleen <ak@...ux.intel.com>
Date:   Mon Jul 2 17:27:04 2012 -0700

     floppy: Run floppy initialization asynchronous

     floppy_init is quite slow, 3s on my test system to determine
     that there is no floppy. Run it asynchronous to the other
     init calls to improve boot time.

     [jkosina@...e.cz: fix modular build]

     Signed-off-by: Andi Kleen <ak@...ux.intel.com>
     Signed-off-by: Jiri Kosina <jkosina@...e.cz>




Wallak wrote:
> Chris Friesen wrote:
>> On 10/26/2012 01:43 PM, Wallak wrote:
>>> Chris Friesen wrote:
>>>> On 10/25/2012 04:49 PM, Wallak wrote:
>>>>> I've a very annoying behavior with the linux-3.6.x kernels 
>>>>> release, and
>>>>> a monolithic configuration. The USB 2.0 drives are mapped first with
>>>>> /dev/sda, /dev/sdb... devices, and than the SATA AHCI drives come 
>>>>> after.
>>>>> This is out of order with the BIOS configuration and breaks a program
>>>>> like lilo. This is also annoying when we use a static partition 
>>>>> mapping.
>>>>>
>>>>> Linux-3.5 works fine. Where this bug come from ? Is this a patch 
>>>>> to get
>>>>> the old, and classical behavior ?
>>>>
>>>> As you have discovered it's fragile to rely on /dev/sd* names since a
>>>> BIOS update, kernel update, or motherboard replacement could
>>>> conceivably cause them to change.
>>>>
>>>> Better to use something like partition labels that you control and
>>>> that don't change.
>>>>
>>>> Chris
>>>>
>>> You are right, when we have a configuration with a lot of drvies and
>>> adapters SATA, old SCSI,.. etc. the order may change. But having the
>>> main SATA hard drive defined, as the BIOS boot device, behind external
>>> and removable USB drives is in my opinion a bug.And may lead to 
>>> security
>>> issues (drives with the same label, etc...).
>>>
>>> Using =LABEL, or =UUID with a bootloader like grub or lilo, save the 
>>> the
>>> boot device mapped drive partition number , and so booting on an older
>>> kernel like linux 3.5 will fail. If we remove the external USB drive,
>>> the boot process will fail too...
>>>
>>> So such a bug have to be fix.
>>
>> If you specify "root=LABEL=<label>" as part of the kernel boot args 
>> in grub does it not check the label at boot time?
>
> Using root=LABEL= or root=UUID= don't work on a plain kernel, this 
> feature may be handled by an initrd trick. Otherwise for all non root 
> partitions UUID= work fine.
> Nevertheless not fixing this bug yields some other issues:  Using lilo 
> to launch a second OS (other= option) fail, the command try to parse 
> partitions available on /dev/sda, and miss the real main HDD. Boot 
> drive must be force with lilo options...
> SATA drives have, most of the time, no reason to be behind USB drives. 
> If we want to get a reliable behavior: /dev/sda must be mapped to the 
> BIOS boot device. Using the same behavior as linux-3.5 will be fine.
>
> Wallak.
>
>>
>> Chris
>>
>

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