archive mirror
 help / color / mirror / Atom feed
From: Helen Koike <>
To: Stephen Boyd <>,
Subject: Re: [linux-lvm] [PATCH v12] dm: add support to directly boot to a mapped device
Date: Tue, 4 Jun 2019 14:38:59 -0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Stephen,

On 6/3/19 8:02 PM, Stephen Boyd wrote:
> Quoting Helen Koike (2019-02-21 12:33:34)
>> Add a "create" module parameter, which allows device-mapper targets to be
>> configured at boot time. This enables early use of dm targets in the boot
>> process (as the root device or otherwise) without the need of an initramfs.
>> The syntax used in the boot param is based on the concise format from the
>> dmsetup tool to follow the rule of least surprise:
>>         sudo dmsetup table --concise /dev/mapper/lroot
>> Which is:
>>         dm-mod.create=<name>,<uuid>,<minor>,<flags>,<table>[,<table>+][;<name>,<uuid>,<minor>,<flags>,<table>[,<table>+]+]
>> Where,
>>         <name>          ::= The device name.
>>         <uuid>          ::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | ""
>>         <minor>         ::= The device minor number | ""
>>         <flags>         ::= "ro" | "rw"
>>         <table>         ::= <start_sector> <num_sectors> <target_type> <target_args>
>>         <target_type>   ::= "verity" | "linear" | ...
>> For example, the following could be added in the boot parameters:
>> dm-mod.create="lroot,,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" root=/dev/dm-0
>> Only the targets that were tested are allowed and the ones that doesn't
>> change any block device when the dm is create as read-only. For example,
>> mirror and cache targets are not allowed. The rationale behind this is
>> that if the user makes a mistake, choosing the wrong device to be the
>> mirror or the cache can corrupt data.
>> The only targets allowed are:
>> * crypt
>> * delay
>> * linear
>> * snapshot-origin
>> * striped
>> * verity
>> Co-developed-by: Will Drewry <>
>> Co-developed-by: Kees Cook <>
>> Co-developed-by: Enric Balletbo i Serra <>
>> Signed-off-by: Helen Koike <>
>> ---
> I'm trying to boot a mainline linux kernel on a chromeos device with dm
> verity and a USB stick but it's not working for me even with this patch.
> I've had to hack around two problems:
>  1) rootwait isn't considered
>  2) verity doesn't seem to accept UUID for <hash_dev> or <dev>
> For the first problem, it happens every boot for me because I'm trying
> to boot off of a USB stick and it's behind a hub that takes a few
> seconds to enumerate. If I hack up the code to call dm_init_init() after
> the 'rootdelay' cmdline parameter is used then I can make this work. It
> would be much nicer if the whole mechanism didn't use a late initcall
> though. If it used a hook from prepare_namespace() and then looped
> waiting for devices to create when rootwait was specified it would work.

The patch was implemented with late initcall partially to be contained
in drivers/md/*, but to support rootwait, adding a hook from
prepare_namespace seems the way to go indeed.

> The second problem is that in chromeos we have the bootloader fill out
> the UUID of the kernel partition (%U) and then we have another parameter
> that indicates the offset from that kernel partition to add to the
> kernel partition (typically 1, i.e. PARTNROFF=1) to find the root
> filesystem partition. The way verity seems to work here is that we need
> to specify a path like /dev/sda3 or the major:minor number of the device
> on the commandline to make this work. It would be better if we could add
> in support for the PARTNROFF style that name_to_dev_t() handles so we
> can specify the root partition like we're currently doing. I suspect we
> should be able to add support for this into the device mapper layer so
> that we can specify devices this way.

hmm, I didn't test this yet but at least from what I can see in the
code, verity_ctr() calls dm_get_device() that ends up calling
name_to_dev_t() which should take care of PARTNROFF, this requires a bit
more investigation.

> If it helps, an example commandline I've been using to test out a usb
> stick is as follows:
> dm-mod.create="vroot,,0,ro, 0 4710400 verity 0 8:19 8:19 4096 4096 588800 588800 sha1 9b0a223aedbf74b06442b0f05fbff33c55edd010 414b21fba60a1901e23aec373e994942e991d6762631e54a39bc42411f244bd2"


> Also, the documentation (Documentation/device-mapper/dm-init.txt) says
> we can use a way that doesn't specify so many arguments, but dm verity
> complains about not enough arguments (10) when following the example:
>   vroot,,,ro,
>   0 1740800 verity 254:0 254:0 1740800 sha1
>   76e9be054b15884a9fa85973e9cb274c93afadb6
>   5b3549d54d6c7a3837b9b81ed72e49463a64c03680c47835bef94d768e5646fe;    
> So the documentation needs an update?

Ack, I'll update this.


  reply	other threads:[~2019-06-04 17:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-21 20:33 [linux-lvm] [PATCH v12] dm: add support to directly boot to a mapped device Helen Koike
2019-02-21 22:42 ` Kees Cook
2019-06-03 23:02 ` Stephen Boyd
2019-06-04 17:38   ` Helen Koike [this message]
2019-06-04 19:21     ` Ezequiel Garcia
2019-06-04 19:35     ` Stephen Boyd
2019-06-05  8:35       ` [linux-lvm] [dm-devel] " Zdenek Kabelac

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).