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, 19 Apr 2010 22:20:23 +1200
From:	skitching@...che.org
To:	linux-kernel@...r.kernel.org
Subject: Re: boot device order troubleshooting without an initrd

As it happens, I've been looking into this issue recently.
[Warning: kernel newbie speaking!]

Without an initrd, the options for the root= kernel parameters are only those supported in init/do_mount.c:
  1.   root=MAJOR:MINOR
  2.   root=integer   where integer is MAJOR<<n + minor
  3    root=/dev/xxx
(well, apart fron "mtd" and "ubi" options).

Unfortunately, all of these options are sensitive to hardware changes, ie device enumeration order. So I 
think that right now the answer to your question is: no, you can't get what you want without an initrd.

And I doubt that changes to the linux device-enumeration code "to be consistent with the BIOS" would be accepted.

Perhaps one thing that could be reasonably easily supported is:
  root=gptguid
where gptguid is the id of a partition on a GPT-formatted disk. With msdos partition tables, partitions do not
have unique identifiers; Windows does puts a 32-bit "windows nt disk signature" field in the MBR, which could
possibly be used but it isn't really standard. However the GPT format (part of the EFI standard) mandates a
unique GUID be assigned to every partition which sounds like an excellent way to specify the location of the
root fs.

I *think* that it would be a matter of enhancing the "struct hd_struct" held by "struct gendisk" to store this
info when scanning a GPT partition table, then enhancing do_mount.c to check the root param against these values.

See: http://en.wikipedia.org/wiki/GUID_Partition_Table

Thoughts?

If this sounds sane to people, I would be keen to have a go at implementing this. Are there any specific
people or lists that should be cc'd when discussing this?

Regards, Simon

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