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: <508AE7D7.309@free.fr>
Date:	Fri, 26 Oct 2012 21:43:19 +0200
From:	Wallak <wallak@...e.fr>
To:	Chris Friesen <chris.friesen@...band.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0
 drives and a monolithic kernel configuration)

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.


Wallak.

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