How does kernel find root filesystem at boot?

[T N]

Within dm="....", is payload=KERNEL-GUID+1 where the location of the root filesystem is passed into the kernel during boot?  (Chrome OS devices)

From /proc/cmdline (see below):

payload=42218a2c-27af-a149-bc0c-7975b9a8e28b+1

Trying to confirm. I am not finding current code/documentation- none of what I find matches current kernel command line.

Thank you,

Trever

cat /proc/cmdline:

cros_secure  loglevel=7 console= init=/sbin/init cros_secure root=/dev/dm-0 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="1 vroot none ro 1,0 2097152 verity payload=42218a2c-27af-a149-bc0c-7975b9a8e28b+1 hashtree=42218a2c-27af-a149-bc0c-7975b9a8e28b+1 hashstart=2097152 alg=sha1 root_hexdigest=f99835bc4e44eb4f717564b0aa48971503dc88db salt=e67840f977911bca10efa61b7e7f15dda6b7e13ad04681088f679dd408739664" noinitrd vt.global_cursor_default=0 kern_guid=42218a2c-27af-a149-bc0c-7975b9a8e28b add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic

[Will Drewry]

On Fri, Mar 22, 2013 at 1:41 PM, T N <trr...@gmail.com> wrote:
> Within dm="....", is payload=KERNEL-GUID+1 where the location of the root
> filesystem is passed into the kernel during boot? (Chrome OS devices)
>
> From /proc/cmdline (see below):
>
> payload=42218a2c-27af-a149-bc0c-7975b9a8e28b+1
>
>
> Trying to confirm. I am not finding current code/documentation- none of what
> I find matches current kernel command line.

KERNEL_GUID+1 is the now old way of expressing
PARTUUID=[guid]/PARTNOFF=1 which the kernel supports itself. The
kernel guid is supplied by the firmware by replacing %U in the kernel
cmdline after it has signature checked it. We always keep the kernel
partition one before the root part (and dm-verity enforces that this
is true by integrity checking the blocks).

The %U should be defined in vboot_reference.git and if you run
dump_kernel_config /dev/sda2 (or whatever) you'll see the signed
config and not the runtime one. (vbutil_kernel can also give you this
info).

hth!
will

[T N]

On Fri, Mar 22, 2013 at 11:45 AM, Will Drewry <w...@chromium.org> wrote:

KERNEL_GUID+1 is the now old way of expressing
PARTUUID=[guid]/PARTNOFF=1 which the kernel supports itself.   The
kernel guid is supplied by the firmware by replacing %U in the kernel
cmdline after it has signature checked it.  We always keep the kernel
partition one before the root part (and dm-verity enforces that this
is true by integrity checking the blocks).

Okay.  Yes this helps.

And I already know about %U.  I follow you there.  Likewise the partitioning order convention (root comes after kernel).

I'm a little unclear what you're saying about what the kernel supports itself (the new way of expressing partition).  I'm looking into that.

But what I really care about here is that you seem to be saying this is right:

1.  Kernel gets location of root filesystem from command line (/proc/cmdline)

2.  On command line, within dm="stuff", there is payload=value, and that is where the location of the root filesystem is specified.

Specifically, the value of the payload parameter is the location of the root filesystem, however that is expressed.

Correct?

[Will Drewry]

On Fri, Mar 22, 2013 at 2:53 PM, T N <trr...@gmail.com> wrote:
> On Fri, Mar 22, 2013 at 11:45 AM, Will Drewry <w...@chromium.org> wrote:
>>
>> KERNEL_GUID+1 is the now old way of expressing
>> PARTUUID=[guid]/PARTNOFF=1 which the kernel supports itself. The
>> kernel guid is supplied by the firmware by replacing %U in the kernel
>> cmdline after it has signature checked it. We always keep the kernel
>> partition one before the root part (and dm-verity enforces that this
>> is true by integrity checking the blocks).
>
>
> Okay. Yes this helps.
>
> And I already know about %U. I follow you there. Likewise the partitioning
> order convention (root comes after kernel).
>
> I'm a little unclear what you're saying about what the kernel supports
> itself (the new way of expressing partition). I'm looking into that.

Ah yeah. Normally the kernel parses its commandline looking for
"root=XXX". We tell it to use root=/dev/dm-0 (or dm-1 depending).
That represents the device-mapper device we want to treat as our root.

dm="" setups of the device mapper device we will treat as root. In
this case, payload= points to the real root drive, and then dm-verity
uses that to setup /dev/dm-0. When /dev/dm-0 becomes available, the
kernel continues ot boot.

> But what I really care about here is that you seem to be saying this is
> right:
>
> 1. Kernel gets location of root filesystem from command line
> (/proc/cmdline)

Yup: root=/dev/dm-0

> 2. On command line, within dm="stuff", there is payload=value, and that is
> where the location of the root filesystem is specified.

dm="stuff" -> dm-verity(%U+1) -> /dev/dm-0

> Specifically, the value of the payload parameter is the location of the root
> filesystem, however that is expressed.

Yup. The %U is the partition uuid. This is populated in the kernel
when it scans the partition table for block devices on the system.
Then the dm-verity code uses the partuuid to search through the block
devices for the matching partition uuid. This is the same as the code
is in the kernel if you do "root=PARTUUID=xxyyzz/PARTNROFF=1".
http://lxr.linux.no/linux+v3.8.4/init/do_mounts.c#L190

We haven't managed to get dm="blah" upstream yet, but I should try
again sometime soon.

Does that make more sense? Thanks!
will

[T N]

On Fri, Mar 22, 2013 at 1:04 PM, Will Drewry <w...@chromium.org> wrote:

Ah yeah. Normally the kernel parses its commandline looking for

"root=XXX".  We tell it to use root=/dev/dm-0 (or dm-1 depending).
That represents the device-mapper device we want to treat as our root.

dm="" setups of the device mapper device we will treat as root.  In
this case, payload= points to the real root drive, and then dm-verity
uses that to setup /dev/dm-0.  When /dev/dm-0 becomes available, the
kernel continues ot boot.

Yup: root=/dev/dm-0

dm="stuff" -> dm-verity(%U+1) -> /dev/dm-0

Yup. The %U is the partition uuid. This is populated in the kernel
when it scans the partition table for block devices on the system.
Then the dm-verity code uses the partuuid to search through the block
devices for the matching partition uuid.  This is the same as the code
is in the kernel if you do "root=PARTUUID=xxyyzz/PARTNROFF=1".
  http://lxr.linux.no/linux+v3.8.4/init/do_mounts.c#L190

We haven't managed to get dm="blah" upstream yet, but I should try
again sometime soon.

Does that make more sense?  Thanks!
will

YES.  All is clear. 

Basically everything is the way I had deduced (including root=/dev/dm-0).  Whew.  :-)

I just wanted to make sure. 

Don't want the doc to be incorrect and I would love it if qualified people will review the doc for technical accuracy when done.

Thanks much!

Trever