From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id C6C557D04D for ; Thu, 21 Feb 2019 20:33:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726152AbfBUUdu (ORCPT ); Thu, 21 Feb 2019 15:33:50 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:54012 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725866AbfBUUdt (ORCPT ); Thu, 21 Feb 2019 15:33:49 -0500 Received: from localhost.localdomain (unknown [IPv6:2804:431:9719:d069:768d:a1f3:f2fe:3241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: koike) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 0F835280B84; Thu, 21 Feb 2019 20:33:42 +0000 (GMT) From: Helen Koike To: dm-devel@redhat.com Cc: wad@chromium.org, keescook@chromium.org, snitzer@redhat.com, linux-doc@vger.kernel.org, richard.weinberger@gmail.com, linux-kernel@vger.kernel.org, linux-lvm@redhat.com, enric.balletbo@collabora.com, kernel@collabora.com, agk@redhat.com Subject: [PATCH v12] dm: add support to directly boot to a mapped device Date: Thu, 21 Feb 2019 17:33:34 -0300 Message-Id: <20190221203334.24504-1-helen.koike@collabora.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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=,,,,[,
+][;,,,,
[,
+]+] Where, ::= The device name. ::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | "" ::= The device minor number | "" ::= "ro" | "rw"
::= ::= "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 --- Hello, Just re-sending updating the patch header. Thanks Helen Changes in v12: - commit message updated - v11: https://www.redhat.com/archives/dm-devel/2019-February/msg00108.html Changes in v11: - Configure the device directly instead of performing in IOCTL (this removed a lot of parsing code) - Just enable the targets that were tested. - Simplify/refactor parsing, as a consequence, escaping characters is not allowed (but it wans't properly used in the previous version anyway) - don't use sscanf, the size wans't being limited and we could have a buffer overflow. - change constrained targets list - remove code from init/ - use a module parameter instead of a kernel comand line parameter in init/ - rename dm-boot to dm-init Changes in v10: - https://lore.kernel.org/patchwork/project/lkml/list/?series=371523 - new file: drivers/md/dm-boot.c - most of the parsing code was moved from init/do_mounts_dm.c to drivers/md/dm-boot.c - parsing code was in essence replaced by the concise parser from dmsetup _create_concise function: https://sourceware.org/git/?p=lvm2.git;a=blob;f=libdm/dm-tools/dmsetup.c;h=835fdcdc75e8f0f0f7c4ed46cc9788a6616f58b8;hb=7498f8383397a93db95655ca227257836cbcac82#l1265 the main reason is that this code is already being used/tested by dmsetup, so we can have some level of confidence that it works as expected. Besides this, it also looks more efficient. - Not all targets are allowed to be used by dm=, as pointed previously, there are some risks in creating a mapped device without some validation from userspace (see documentation from the patch listing which targets are allowed). - Instead of using a simple singly linked list (for devices and tables), use the struct list_head. This occupies unnecessary space in the code, but it makes the code cleaner and easier to read and less prone to silly errors. - Documentation and comments were reviewed and refactored, e.g.: * "is to possible" was removed * s/specified as a simple string/specified as a string/ - Added docs above __align function, make it clear that the second parameter @a must be a power of two. - Clean ups: removal of unnecessary includes, macros, variables, some redundant checks and warnings. - when calling ioctls, the code was allocating and freeing the same structure a couple of times. So instead of executing kzalloc/kfree 3 times, execute kmalloc once and reuse the structure after a memset, then finally kfree it once. - update commit message Changes in v9: - https://www.redhat.com/archives/linux-lvm/2018-September/msg00016.html - Add minor number to make it compatible with dmsetup concise format Changes in v8: - https://www.redhat.com/archives/linux-lvm/2017-May/msg00055.html - Fix build error due commit e516db4f67 (dm ioctl: add a new DM_DEV_ARM_POLL ioctl) Changes in v7: - http://lkml.iu.edu/hypermail/linux/kernel/1705.2/02657.html - Add a new function to issue the equivalent of a DM ioctl programatically. - Use the new ioctl interface to create the devices. - Use a comma-delimited and semi-colon delimited dmsetup-like commands. Changes in v6: - https://www.redhat.com/archives/dm-devel/2017-April/msg00316.html Changes in v5: - https://www.redhat.com/archives/dm-devel/2016-February/msg00112.html Documentation/device-mapper/dm-init.txt | 114 +++++++++ drivers/md/Kconfig | 10 + drivers/md/Makefile | 4 + drivers/md/dm-init.c | 308 ++++++++++++++++++++++++ drivers/md/dm-ioctl.c | 103 ++++++++ include/linux/device-mapper.h | 9 + 6 files changed, 548 insertions(+) create mode 100644 Documentation/device-mapper/dm-init.txt create mode 100644 drivers/md/dm-init.c diff --git a/Documentation/device-mapper/dm-init.txt b/Documentation/device-mapper/dm-init.txt new file mode 100644 index 000000000000..8464ee7c01b8 --- /dev/null +++ b/Documentation/device-mapper/dm-init.txt @@ -0,0 +1,114 @@ +Early creation of mapped devices +==================================== + +It is possible to configure a device-mapper device to act as the root device for +your system in two ways. + +The first is to build an initial ramdisk which boots to a minimal userspace +which configures the device, then pivot_root(8) in to it. + +The second is to create one or more device-mappers using the module parameter +"dm-mod.create=" through the kernel boot command line argument. + +The format is specified as a string of data separated by commas and optionally +semi-colons, where: + - a comma is used to separate fields like name, uuid, flags and table + (specifies one device) + - a semi-colon is used to separate devices. + +So the format will look like this: + + dm-mod.create=,,,,
[,
+][;,,,,
[,
+]+] + +Where, + ::= The device name. + ::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | "" + ::= The device minor number | "" + ::= "ro" | "rw" +
::= + ::= "verity" | "linear" | ... (see list below) + +The dm line should be equivalent to the one used by the dmsetup tool with the +--concise argument. + +Target types +============ + +Not all target types are available as there are serious risks in allowing +activation of certain DM targets without first using userspace tools to check +the validity of associated metadata. + + "cache": constrained, userspace should verify cache device + "crypt": allowed + "delay": allowed + "era": constrained, userspace should verify metadata device + "flakey": constrained, meant for test + "linear": allowed + "log-writes": constrained, userspace should verify metadata device + "mirror": constrained, userspace should verify main/mirror device + "raid": constrained, userspace should verify metadata device + "snapshot": constrained, userspace should verify src/dst device + "snapshot-origin": allowed + "snapshot-merge": constrained, userspace should verify src/dst device + "striped": allowed + "switch": constrained, userspace should verify dev path + "thin": constrained, requires dm target message from userspace + "thin-pool": constrained, requires dm target message from userspace + "verity": allowed + "writecache": constrained, userspace should verify cache device + "zero": constrained, not meant for rootfs + +If the target is not listed above, it is constrained by default (not tested). + +Examples +======== +An example of booting to a linear array made up of user-mode linux block +devices: + + dm-mod.create="lroot,,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" root=/dev/dm-0 + +This will boot to a rw dm-linear target of 8192 sectors split across two block +devices identified by their major:minor numbers. After boot, udev will rename +this target to /dev/mapper/lroot (depending on the rules). No uuid was assigned. + +An example of multiple device-mappers, with the dm-mod.create="..." contents is shown here +split on multiple lines for readability: + + vroot,,,ro, + 0 1740800 verity 254:0 254:0 1740800 sha1 + 76e9be054b15884a9fa85973e9cb274c93afadb6 + 5b3549d54d6c7a3837b9b81ed72e49463a64c03680c47835bef94d768e5646fe; + vram,,,rw, + 0 32768 linear 1:0 0, + 32768 32768 linear 1:1 0 + +Other examples (per target): + +"crypt": + dm-crypt,,8,ro, + 0 1048576 crypt aes-xts-plain64 + babebabebabebabebabebabebabebabebabebabebabebabebabebabebabebabe 0 + /dev/sda 0 1 allow_discards + +"delay": + dm-delay,,4,ro,0 409600 delay /dev/sda1 0 500 + +"linear": + dm-linear,,,rw, + 0 32768 linear /dev/sda1 0, + 32768 1024000 linear /dev/sda2 0, + 1056768 204800 linear /dev/sda3 0, + 1261568 512000 linear /dev/sda4 0 + +"snapshot-origin": + dm-snap-orig,,4,ro,0 409600 snapshot-origin 8:2 + +"striped": + dm-striped,,4,ro,0 1638400 striped 4 4096 + /dev/sda1 0 /dev/sda2 0 /dev/sda3 0 /dev/sda4 0 + +"verity": + dm-verity,,4,ro, + 0 1638400 verity 1 8:1 8:2 4096 4096 204800 1 sha256 + fb1a5a0f00deb908d8b53cb270858975e76cf64105d412ce764225d53b8f3cfd + 51934789604d1b92399c52e7cb149d1b3a1b74bbbcb103b2a0aaacbed5c08584 diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig index 3db222509e44..644e868cc2eb 100644 --- a/drivers/md/Kconfig +++ b/drivers/md/Kconfig @@ -436,6 +436,16 @@ config DM_DELAY If unsure, say N. +config DM_INIT + bool "DM \"dm-mod.create=\" parameter support" + depends on BLK_DEV_DM=y + ---help--- + Enable "dm-mod.create=" parameter to create mapped devices at init time. + This option is useful to allow mounting rootfs without requiring an + initramfs. + See Documentation/device-mapper/dm-init.txt for dm-mod.create="..." + format + config DM_UEVENT bool "DM uevents" depends on BLK_DEV_DM diff --git a/drivers/md/Makefile b/drivers/md/Makefile index 822f4e8753bc..a52b703e588e 100644 --- a/drivers/md/Makefile +++ b/drivers/md/Makefile @@ -69,6 +69,10 @@ obj-$(CONFIG_DM_INTEGRITY) += dm-integrity.o obj-$(CONFIG_DM_ZONED) += dm-zoned.o obj-$(CONFIG_DM_WRITECACHE) += dm-writecache.o +ifeq ($(CONFIG_DM_INIT),y) +dm-mod-objs += dm-init.o +endif + ifeq ($(CONFIG_DM_UEVENT),y) dm-mod-objs += dm-uevent.o endif diff --git a/drivers/md/dm-init.c b/drivers/md/dm-init.c new file mode 100644 index 000000000000..24ea75911c7c --- /dev/null +++ b/drivers/md/dm-init.c @@ -0,0 +1,308 @@ +// SPDX-License-Identifier: GPL-2.0 + +/* + * dm-init.c + * Copyright (C) 2017 The Chromium OS Authors + * + * This file is released under the GPLv2. + */ + +#include +#include +#include +#include +#include +#include + +#define DM_MSG_PREFIX "dm" +#define DM_MAX_DEVICES 256 +#define DM_MAX_TARGETS 256 +#define DM_MAX_STR_SIZE 4096 + +static char *create; + +/* + * Format: dm-mod.create=,,,,
[,
+][;,,,,
[,
+]+] + * Table format: + * + * See Documentation/device-mapper/dm-init.txt for dm-mod.create="..." format + * details. + */ + +struct dm_device { + struct dm_ioctl dmi; + struct dm_target_spec *table[DM_MAX_TARGETS]; + char *target_args_array[DM_MAX_TARGETS]; + struct list_head list; +}; + +const char *dm_allowed_targets[] __initconst = { + "crypt", + "delay", + "linear", + "snapshot-origin", + "striped", + "verity", +}; + +static int __init dm_verify_target_type(const char *target) +{ + unsigned int i; + + for (i = 0; i < ARRAY_SIZE(dm_allowed_targets); i++) { + if (!strcmp(dm_allowed_targets[i], target)) + return 0; + } + return -EINVAL; +} + +static void __init dm_setup_cleanup(struct list_head *devices) +{ + struct dm_device *dev, *tmp; + unsigned int i; + + list_for_each_entry_safe(dev, tmp, devices, list) { + list_del(&dev->list); + for (i = 0; i < dev->dmi.target_count; i++) { + kfree(dev->table[i]); + kfree(dev->target_args_array[i]); + } + kfree(dev); + } +} + +/** + * str_field_delimit - delimit a string based on a separator char. + * @str: the pointer to the string to delimit. + * @separator: char that delimits the field + * + * Find a @separator and replace it by '\0'. + * Remove leading and trailing spaces. + * Return the remainder string after the @separator. + */ +static char __init *str_field_delimit(char **str, char separator) +{ + char *s; + + /* TODO: add support for escaped characters */ + *str = skip_spaces(*str); + s = strchr(*str, separator); + /* Delimit the field and remove trailing spaces */ + if (s) + *s = '\0'; + *str = strim(*str); + return s ? ++s : NULL; +} + +/** + * dm_parse_table_entry - parse a table entry + * @dev: device to store the parsed information. + * @str: the pointer to a string with the format: + * [, ...] + * + * Return the remainder string after the table entry, i.e, after the comma which + * delimits the entry or NULL if reached the end of the string. + */ +static char __init *dm_parse_table_entry(struct dm_device *dev, char *str) +{ + const unsigned int n = dev->dmi.target_count - 1; + struct dm_target_spec *sp; + unsigned int i; + /* fields: */ + char *field[4]; + char *next; + + field[0] = str; + /* Delimit first 3 fields that are separated by space */ + for (i = 0; i < ARRAY_SIZE(field) - 1; i++) { + field[i + 1] = str_field_delimit(&field[i], ' '); + if (!field[i + 1]) + return ERR_PTR(-EINVAL); + } + /* Delimit last field that can be terminated by comma */ + next = str_field_delimit(&field[i], ','); + + sp = kzalloc(sizeof(*sp), GFP_KERNEL); + if (!sp) + return ERR_PTR(-ENOMEM); + dev->table[n] = sp; + + /* start_sector */ + if (kstrtoull(field[0], 0, &sp->sector_start)) + return ERR_PTR(-EINVAL); + /* num_sector */ + if (kstrtoull(field[1], 0, &sp->length)) + return ERR_PTR(-EINVAL); + /* target_type */ + strscpy(sp->target_type, field[2], sizeof(sp->target_type)); + if (dm_verify_target_type(sp->target_type)) { + DMERR("invalid type \"%s\"", sp->target_type); + return ERR_PTR(-EINVAL); + } + /* target_args */ + dev->target_args_array[n] = kstrndup(field[3], GFP_KERNEL, + DM_MAX_STR_SIZE); + if (!dev->target_args_array[n]) + return ERR_PTR(-ENOMEM); + + return next; +} + +/** + * dm_parse_table - parse "dm-mod.create=" table field + * @dev: device to store the parsed information. + * @str: the pointer to a string with the format: + *
[,
+] + */ +static int __init dm_parse_table(struct dm_device *dev, char *str) +{ + char *table_entry = str; + + while (table_entry) { + DMDEBUG("parsing table \"%s\"", str); + if (++dev->dmi.target_count >= DM_MAX_TARGETS) { + DMERR("too many targets %u > %d", + dev->dmi.target_count, DM_MAX_TARGETS); + return -EINVAL; + } + table_entry = dm_parse_table_entry(dev, table_entry); + if (IS_ERR(table_entry)) { + DMERR("couldn't parse table"); + return PTR_ERR(table_entry); + } + } + + return 0; +} + +/** + * dm_parse_device_entry - parse a device entry + * @dev: device to store the parsed information. + * @str: the pointer to a string with the format: + * name,uuid,minor,flags,table[; ...] + * + * Return the remainder string after the table entry, i.e, after the semi-colon + * which delimits the entry or NULL if reached the end of the string. + */ +static char __init *dm_parse_device_entry(struct dm_device *dev, char *str) +{ + /* There are 5 fields: name,uuid,minor,flags,table; */ + char *field[5]; + unsigned int i; + char *next; + + field[0] = str; + /* Delimit first 4 fields that are separated by comma */ + for (i = 0; i < ARRAY_SIZE(field) - 1; i++) { + field[i+1] = str_field_delimit(&field[i], ','); + if (!field[i+1]) + return ERR_PTR(-EINVAL); + } + /* Delimit last field that can be delimited by semi-colon */ + next = str_field_delimit(&field[i], ';'); + + /* name */ + strscpy(dev->dmi.name, field[0], sizeof(dev->dmi.name)); + /* uuid */ + strscpy(dev->dmi.uuid, field[1], sizeof(dev->dmi.uuid)); + /* minor */ + if (strlen(field[2])) { + if (kstrtoull(field[2], 0, &dev->dmi.dev)) + return ERR_PTR(-EINVAL); + dev->dmi.flags |= DM_PERSISTENT_DEV_FLAG; + } + /* flags */ + if (!strcmp(field[3], "ro")) + dev->dmi.flags |= DM_READONLY_FLAG; + else if (strcmp(field[3], "rw")) + return ERR_PTR(-EINVAL); + /* table */ + if (dm_parse_table(dev, field[4])) + return ERR_PTR(-EINVAL); + + return next; +} + +/** + * dm_parse_devices - parse "dm-mod.create=" argument + * @devices: list of struct dm_device to store the parsed information. + * @str: the pointer to a string with the format: + * [;+] + */ +static int __init dm_parse_devices(struct list_head *devices, char *str) +{ + unsigned long ndev = 0; + struct dm_device *dev; + char *device = str; + + DMDEBUG("parsing \"%s\"", str); + while (device) { + dev = kzalloc(sizeof(*dev), GFP_KERNEL); + if (!dev) + return -ENOMEM; + list_add_tail(&dev->list, devices); + + if (++ndev >= DM_MAX_DEVICES) { + DMERR("too many targets %u > %d", + dev->dmi.target_count, DM_MAX_TARGETS); + return -EINVAL; + } + + device = dm_parse_device_entry(dev, device); + if (IS_ERR(device)) { + DMERR("couldn't parse device"); + return PTR_ERR(device); + } + } + + return 0; +} + +/** + * dm_init_init - parse "dm-mod.create=" argument and configure drivers + */ +static int __init dm_init_init(void) +{ + struct dm_device *dev; + LIST_HEAD(devices); + char *str; + int r; + + if (!create) + return 0; + + if (strlen(create) >= DM_MAX_STR_SIZE) { + DMERR("Argument is too big. Limit is %d\n", DM_MAX_STR_SIZE); + return -EINVAL; + } + str = kstrndup(create, GFP_KERNEL, DM_MAX_STR_SIZE); + if (!str) + return -ENOMEM; + + r = dm_parse_devices(&devices, str); + if (r) + goto out; + + DMINFO("waiting for all devices to be available before creating mapped devices\n"); + wait_for_device_probe(); + + list_for_each_entry(dev, &devices, list) { + if (dm_early_create(&dev->dmi, dev->table, + dev->target_args_array)) + break; + } +out: + kfree(str); + dm_setup_cleanup(&devices); + return r; +} + +late_initcall(dm_init_init); + +module_param(create, charp, 0); +MODULE_PARM_DESC(create, "Create a mapped device when the module is loaded using this argument\n" + "This is mostly useful in early boot to allow mounting rootfs without requiring an initramfs\n" + "Format: ,,,,
[,
+][;,,,,
[,
+]+]\n" + "Table format: \n" + "Examples:\n" + "dm-mod.create=\"lroot,,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0\"\n"); diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c index f666778ad237..c740153b4e52 100644 --- a/drivers/md/dm-ioctl.c +++ b/drivers/md/dm-ioctl.c @@ -2018,3 +2018,106 @@ int dm_copy_name_and_uuid(struct mapped_device *md, char *name, char *uuid) return r; } + + +/** + * dm_early_create - create a mapped device in early boot. + * + * @dmi: Contains main information of the device mapping to be created. + * @spec_array: array of pointers to struct dm_target_spec. Describes the + * mapping table of the device. + * @target_params_array: array of strings with the parameters to a specific + * target. + * + * Instead of having the struct dm_target_spec and the parameters for every + * target embedded at the end of struct dm_ioctl (as performed in a normal + * ioctl), pass them as arguments, so the caller doesn't need to serialize them. + * The size of the spec_array and target_params_array is given by + * @dmi->target_count. + * This function is supposed to be called in early boot, so locking mechanisms + * to protect against concurrent loads are not required. + */ +int __init dm_early_create(struct dm_ioctl *dmi, + struct dm_target_spec **spec_array, + char **target_params_array) +{ + int r, m = DM_ANY_MINOR; + struct dm_table *t, *old_map; + struct mapped_device *md; + unsigned int i; + + if (!dmi->target_count) + return -EINVAL; + + r = check_name(dmi->name); + if (r) + return r; + + if (dmi->flags & DM_PERSISTENT_DEV_FLAG) + m = MINOR(huge_decode_dev(dmi->dev)); + + /* alloc dm device */ + r = dm_create(m, &md); + if (r) + return r; + + /* hash insert */ + r = dm_hash_insert(dmi->name, *dmi->uuid ? dmi->uuid : NULL, md); + if (r) + goto err_destroy_dm; + + /* alloc table */ + r = dm_table_create(&t, get_mode(dmi), dmi->target_count, md); + if (r) + goto err_destroy_dm; + + /* add targets */ + for (i = 0; i < dmi->target_count; i++) { + r = dm_table_add_target(t, spec_array[i]->target_type, + (sector_t) spec_array[i]->sector_start, + (sector_t) spec_array[i]->length, + target_params_array[i]); + if (r) { + DMWARN("error adding target to table"); + goto err_destroy_table; + } + } + + /* finish table */ + r = dm_table_complete(t); + if (r) + goto err_destroy_table; + + md->type = dm_table_get_type(t); + /* setup md->queue to reflect md's type (may block) */ + r = dm_setup_md_queue(md, t); + if (r) { + DMWARN("unable to set up device queue for new table."); + goto err_destroy_table; + } + + /* Set new map */ + dm_suspend(md, 0); + old_map = dm_swap_table(md, t); + if (IS_ERR(old_map)) { + r = PTR_ERR(old_map); + goto err_destroy_table; + } + set_disk_ro(dm_disk(md), !!(dmi->flags & DM_READONLY_FLAG)); + + /* resume device */ + r = dm_resume(md); + if (r) + goto err_destroy_table; + + DMINFO("%s (%s) is ready", md->disk->disk_name, dmi->name); + dm_put(md); + return 0; + +err_destroy_table: + dm_table_destroy(t); +err_destroy_dm: + dm_put(md); + dm_destroy(md); + return r; +} diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h index e528baebad69..8fa618381e78 100644 --- a/include/linux/device-mapper.h +++ b/include/linux/device-mapper.h @@ -10,6 +10,7 @@ #include #include +#include #include #include @@ -431,6 +432,14 @@ void dm_remap_zone_report(struct dm_target *ti, sector_t start, struct blk_zone *zones, unsigned int *nr_zones); union map_info *dm_get_rq_mapinfo(struct request *rq); +/* + * Device mapper functions to parse and create devices specified by the + * parameter "dm-mod.create=" + */ +int __init dm_early_create(struct dm_ioctl *dmi, + struct dm_target_spec **spec_array, + char **target_params_array); + struct queue_limits *dm_get_queue_limits(struct mapped_device *md); /* -- 2.20.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 3198E7D099 for ; Thu, 21 Feb 2019 22:43:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726074AbfBUWnD (ORCPT ); Thu, 21 Feb 2019 17:43:03 -0500 Received: from mail-ua1-f68.google.com ([209.85.222.68]:34880 "EHLO mail-ua1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725891AbfBUWnD (ORCPT ); Thu, 21 Feb 2019 17:43:03 -0500 Received: by mail-ua1-f68.google.com with SMTP id f88so265151uaf.2 for ; Thu, 21 Feb 2019 14:43:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yeeHN5A8TYuXfyBLqkC461JBDCYqSC4jUmx5jzSnVf8=; b=HtJsTwMZ/y6bodUGz8ah6aWBE3c5suzmjH4E3AscE/Q0tKHjQ0EQyLo22c9SGNSZID feywrxucg+iY26CdlDvcsjAEzrTIy5kXaAVoUzrKJUmenp3tjnpB62AMFm+D8MJJ7GYJ GOqZIAqTnGopfeQD2vySUflTZPZUYpRUV3zEU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yeeHN5A8TYuXfyBLqkC461JBDCYqSC4jUmx5jzSnVf8=; b=DAs5CQhSTpk5OoasfGmJdTk8V2lSko9eWi0afiCzsPq1aHfwKjAFvNJeiL3LYM08jS a93biAz8iF7MUdR2OYnjcwhtL2WfuG507v6VazbomPEAFK3JZY1Yec8BBEDB8sXMuBp+ BuY/FMBmULL7pqjpTzv8cMx0DR0/qokCA7xxrlV5vSI4oiq+GIE7WjaiHRBz8qVWNatc f74JP0eQO+wP9HbA/wFHyOpAnNcPyMHMHEjLQ7V72t71wAuB6ZFK8UUr18EbDN9dx3Tn CdBBRnIZlJtWr54hnm1DzOx8S7uni8oNvx+LLpCmPjW2URsI43n4UiJ6tlI9LxbK4nax cbGA== X-Gm-Message-State: AHQUAuazC6W1OGQYwimZvpzzPMAi8sT+vYo5IbtFnHLku1uqnxVCou2l IP2DM1fk/MchRt4nMm6Jso60D0wh+PA= X-Google-Smtp-Source: AHgI3IZzAb5q8wZyev/3rT/MapTcJWG75k7+oyeUIy6r1WSJNsJaxmvMUMVM3rJ8KqZvuJ7geFFo6w== X-Received: by 2002:ab0:234c:: with SMTP id h12mr556402uao.92.1550788981885; Thu, 21 Feb 2019 14:43:01 -0800 (PST) Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com. [209.85.221.170]) by smtp.gmail.com with ESMTPSA id o6sm34000vkb.15.2019.02.21.14.43.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 14:43:00 -0800 (PST) Received: by mail-vk1-f170.google.com with SMTP id b6so62893vkf.8 for ; Thu, 21 Feb 2019 14:43:00 -0800 (PST) X-Received: by 2002:a1f:a5d3:: with SMTP id o202mr621947vke.40.1550788979940; Thu, 21 Feb 2019 14:42:59 -0800 (PST) MIME-Version: 1.0 References: <20190221203334.24504-1-helen.koike@collabora.com> In-Reply-To: <20190221203334.24504-1-helen.koike@collabora.com> From: Kees Cook Date: Thu, 21 Feb 2019 14:42:47 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v12] dm: add support to directly boot to a mapped device To: Helen Koike Cc: device-mapper development , Will Drewry , Mike Snitzer , "open list:DOCUMENTATION" , richard -rw- weinberger , LKML , linux-lvm@redhat.com, Enric Balletbo i Serra , kernel@collabora.com, Alasdair G Kergon Content-Type: text/plain; charset="UTF-8" Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Thu, Feb 21, 2019 at 12:33 PM Helen Koike wrote: > > 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=,,,,
[,
+][;,,,,
[,
+]+] > > Where, > ::= The device name. > ::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | "" > ::= The device minor number | "" > ::= "ro" | "rw" >
::= > ::= "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 Thanks! This appears to have everything Chrome OS needs. I've asked a few other folks to look at it too. Reviewed-by: Kees Cook -- Kees Cook From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE,T_DKIMWL_WL_HIGH autolearn=unavailable autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 941B17D2EF for ; Mon, 3 Jun 2019 23:03:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726583AbfFCXDC (ORCPT ); Mon, 3 Jun 2019 19:03:02 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:38917 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726136AbfFCXDC (ORCPT ); Mon, 3 Jun 2019 19:03:02 -0400 Received: by mail-pg1-f195.google.com with SMTP id 196so9130747pgc.6 for ; Mon, 03 Jun 2019 16:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=message-id:mime-version:content-transfer-encoding:in-reply-to :references:cc:to:from:subject:user-agent:date; bh=M0Hol1AOy0PKp1c8t8OnpXkvg1N8/Tmp5x6wPCFFMsw=; b=Xfn13xPJjjwbLXR9uug3Z3G6LQb+xBE4ONBMi76WHafAXU8u3CBRtuKcEB+IYyRXLD df0YOzJAgsBizPo4j8K2kObvDFTIa00ANWFb0BsDU0KgNxuBCjcQy0Ye0Glb5SZ8I7Uy d0e1kVim0sDFhNYzBkTSEazmw7ZzArabm1gNA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version :content-transfer-encoding:in-reply-to:references:cc:to:from:subject :user-agent:date; bh=M0Hol1AOy0PKp1c8t8OnpXkvg1N8/Tmp5x6wPCFFMsw=; b=e+bV3pAd0kpS/kv40Xx5GWh12DFzemR3zuFla/pK6vchxWUY7Y3RYCt6eFRebmvYlv qlmFWu7+XatpZJsRCMt5MkKJ4u16uup6YOoMsj3eM0YzDMI8h+zxwC+qzYcOmOztMr4l OSIeloHk1IBhkyk6OSNPkR5hMZwoF1znlHF1VttfunL+tAij+yDhfLI8VCHL/+NGFPqY jVBC5oE39AW8h/63EpwSWp7cyO7pK3LDwfIippWxjwV2fYZKAWXOZVRf3uJnTA+O5Vw9 2+rorS3g7PK1neCdEZnYfsaSw7gVq0EwmpgIZGmhgtT7K8r6nxwFyrTPqh2hIcneUYVi 2KhA== X-Gm-Message-State: APjAAAWGxmtIGHHfAwtpxIdx9WaUFGhTAb8+87Xr1g2V6wFX3prxxYqg Naaei2RYyQ4Z/pROfCT6v9TkgQ== X-Google-Smtp-Source: APXvYqxm7Ws5lscObY+oPn1h3+ONhLwXf8YRLVndDfYmndsXiVoHaByRfk1oBLv+cxwcrRXvWyohLg== X-Received: by 2002:a63:6c87:: with SMTP id h129mr32302973pgc.427.1559602981281; Mon, 03 Jun 2019 16:03:01 -0700 (PDT) Received: from chromium.org ([2620:15c:202:1:fa53:7765:582b:82b9]) by smtp.gmail.com with ESMTPSA id c142sm17390174pfb.171.2019.06.03.16.03.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 03 Jun 2019 16:03:00 -0700 (PDT) Message-ID: <5cf5a724.1c69fb81.1e8f0.08fb@mx.google.com> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20190221203334.24504-1-helen.koike@collabora.com> References: <20190221203334.24504-1-helen.koike@collabora.com> Cc: wad@chromium.org, keescook@chromium.org, snitzer@redhat.com, linux-doc@vger.kernel.org, richard.weinberger@gmail.com, linux-kernel@vger.kernel.org, linux-lvm@redhat.com, enric.balletbo@collabora.com, kernel@collabora.com, agk@redhat.com To: Helen Koike , dm-devel@redhat.com From: Stephen Boyd Subject: Re: [PATCH v12] dm: add support to directly boot to a mapped device User-Agent: alot/0.8.1 Date: Mon, 03 Jun 2019 16:02:59 -0700 Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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 initramf= s. >=20 > The syntax used in the boot param is based on the concise format from the > dmsetup tool to follow the rule of least surprise: >=20 > sudo dmsetup table --concise /dev/mapper/lroot >=20 > Which is: > dm-mod.create=3D,,,,
[,
+][= ;,,,,
[,
+]+] >=20 > Where, > ::=3D The device name. > ::=3D xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | "" > ::=3D The device minor number | "" > ::=3D "ro" | "rw" >
::=3D = > ::=3D "verity" | "linear" | ... >=20 > For example, the following could be added in the boot parameters: > dm-mod.create=3D"lroot,,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:3= 2 0" root=3D/dev/dm-0 >=20 > 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. >=20 > The only targets allowed are: > * crypt > * delay > * linear > * snapshot-origin > * striped > * verity >=20 > Co-developed-by: Will Drewry > Co-developed-by: Kees Cook > Co-developed-by: Enric Balletbo i Serra > Signed-off-by: Helen Koike >=20 > --- >=20 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 or 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 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=3D1) 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. If it helps, an example commandline I've been using to test out a usb stick is as follows: dm-mod.create=3D"vroot,,0,ro, 0 4710400 verity 0 8:19 8:19 4096 4096 588800= 588800 sha1 9b0a223aedbf74b06442b0f05fbff33c55edd010 414b21fba60a1901e23ae= c373e994942e991d6762631e54a39bc42411f244bd2" 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; =20 So the documentation needs an update? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id DF0FC7D2F0 for ; Tue, 4 Jun 2019 17:39:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726343AbfFDRjK (ORCPT ); Tue, 4 Jun 2019 13:39:10 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:43716 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725933AbfFDRjK (ORCPT ); Tue, 4 Jun 2019 13:39:10 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: koike) with ESMTPSA id B9B3D260A1E Subject: Re: [PATCH v12] dm: add support to directly boot to a mapped device To: Stephen Boyd , dm-devel@redhat.com Cc: wad@chromium.org, keescook@chromium.org, snitzer@redhat.com, linux-doc@vger.kernel.org, richard.weinberger@gmail.com, linux-kernel@vger.kernel.org, linux-lvm@redhat.com, enric.balletbo@collabora.com, kernel@collabora.com, agk@redhat.com References: <20190221203334.24504-1-helen.koike@collabora.com> <5cf5a724.1c69fb81.1e8f0.08fb@mx.google.com> From: Helen Koike Openpgp: preference=signencrypt Autocrypt: addr=helen.koike@collabora.com; keydata= mQINBFmOMD4BEADb2nC8Oeyvklh+ataw2u/3mrl+hIHL4WSWtii4VxCapl9+zILuxFDrxw1p XgF3cfx7g9taWBrmLE9VEPwJA6MxaVnQuDL3GXxTxO/gqnOFgT3jT+skAt6qMvoWnhgurMGH wRaA3dO4cFrDlLsZIdDywTYcy7V2bou81ItR5Ed6c5UVX7uTTzeiD/tUi8oIf0XN4takyFuV Rf09nOhi24bn9fFN5xWHJooFaFf/k2Y+5UTkofANUp8nn4jhBUrIr6glOtmE0VT4pZMMLT63 hyRB+/s7b1zkOofUGW5LxUg+wqJXZcOAvjocqSq3VVHcgyxdm+Nv0g9Hdqo8bQHC2KBK86VK vB+R7tfv7NxVhG1sTW3CQ4gZb0ZugIWS32Mnr+V+0pxci7QpV3jrtVp5W2GA5HlXkOyC6C7H Ao7YhogtvFehnlUdG8NrkC3HhCTF8+nb08yGMVI4mMZ9v/KoIXKC6vT0Ykz434ed9Oc9pDow VUqaKi3ey96QczfE4NI029bmtCY4b5fucaB/aVqWYRH98Jh8oIQVwbt+pY7cL5PxS7dQ/Zuz 6yheqDsUGLev1O3E4R8RZ8jPcfCermL0txvoXXIA56t4ZjuHVcWEe2ERhLHFGq5Zw7KC6u12 kJoiZ6WDBYo4Dp+Gd7a81/WsA33Po0j3tk/8BWoiJCrjXzhtRwARAQABtCdIZWxlbiBLb2lr ZSA8aGVsZW4ua29pa2VAY29sbGFib3JhLmNvbT6JAlQEEwEKAD4CGwEFCwkIBwMFFQoJCAsF FgIDAQACHgECF4AWIQSofQA6zrItXEgHWTzAfqwo9yFiXQUCXEz3bwUJBKaPRQAKCRDAfqwo 9yFiXdUCD/4+WZr503hQ13KB4DijOW76ju8JDPp4p++qoPxtoAsld3yROoTI+VPWmt7ojHrr TZc7sTLxOFzaUC8HjGTb3r9ilIhIKf/M9KRLkpIJ+iLA+VoUbcSOMYWoVNfgLmbnqoezjPcy OHJwVw9dzEeYpvG6nkY6E4UktANySp27AniSXNuHOvYsOsXmUOqU1ScdsrQ9s732p/OGdTyw 1yd3gUMLZvCKFOBVHILH59HCRJgpwUPiws8G4dGMs4GTRvHT2s2mDQdQ0HEvcM9rvCRVixuC 5ZeOymZNi6lDIUIysgiZ+yzk6i5l/Ni6r7v20N3JppZvhPK6LqtaYceyAGyc3jjnOqoHT/qR kPjCwzmKiPtXjLw6HbRXtGgGtP5m3y8v6bfHH+66zd2vGCY0Z9EsqcnK4DCqRkLncFLPM2gn 9cZcCmO4ZqXUhTyn1nHM494kd5NX1Op4HO+t9ErnpufkVjoMUeBwESdQwwwHT3rjUueGmCrn VJK69/qhA4La72VTxHutl+3Z0Xy20HWsZS8Gsam39f95/LtPLzbBwnOOi5ZoXnm97tF8HrAZ 2h+kcRLMWw3BXy5q4gic+oFZMZP9oq1G9XTFld4FGgJ9ys8aGmhLM+uB1pFxb3XFtWQ2z4AJ iEp2VLl34quwfD6Gg4csiZe2KzvQHUe0w8SJ9LplrHPPprkCDQRZjjChARAAzISLQaHzaDOv ZxcoCNBk/hUGo2/gsmBW4KSj73pkStZ+pm3Yv2CRtOD4jBlycXjzhwBV7/70ZMH70/Y25dJa CnJKl/Y76dPPn2LDWrG/4EkqUzoJkhRIYFUTpkPdaVYznqLgsho19j7HpEbAum8r3jemYBE1 AIuVGg4bqY3UkvuHWLVRMuaHZNy55aYwnUvd46E64JH7O990mr6t/nu2a1aJ0BDdi8HZ0RMo Eg76Avah+YR9fZrhDFmBQSL+mcCVWEbdiOzHmGYFoToqzM52wsNEpo2aStH9KLk8zrCXGx68 ohJyQoALX4sS03RIWh1jFjnlw2FCbEdj/HDX0+U0i9COtanm54arYXiBTnAnx0F7LW7pv7sb 6tKMxsMLmprP/nWyV5AfFRi3jxs5tdwtDDk/ny8WH6KWeLR/zWDwpYgnXLBCdg8l97xUoPQO 0VkKSa4JEXUZWZx9q6kICzFGsuqApqf9gIFJZwUmirsxH80Fe04Tv+IqIAW7/djYpOqGjSyk oaEVNacwLLgZr+/j69/1ZwlbS8K+ChCtyBV4kEPzltSRZ4eU19v6sDND1JSTK9KSDtCcCcAt VGFlr4aE00AD/aOkHSylc93nPinBFO4AGhcs4WypZ3GGV6vGWCpJy9svfWsUDhSwI7GS/i/v UQ1+bswyYEY1Q3DjJqT7fXcAEQEAAYkEcgQYAQoAJgIbAhYhBKh9ADrOsi1cSAdZPMB+rCj3 IWJdBQJcTPfVBQkEpo7hAkDBdCAEGQEKAB0WIQSomGMEg78Cd/pMshveCRfNeJ05lgUCWY4w oQAKCRDeCRfNeJ05lp0gD/49i95kPKjpgjUbYeidjaWuINXMCA171KyaBAp+Jp2Qrun4sIJB Z6srMj6O/gC34AhZln2sXeQdxe88sNbg6HjlN+4AkhTd6DttjOfUwnamLDA7uw+YIapGgsgN lznjLnqOaQ9mtEwRbZMUOdyRf9osSuL14vHl4ia3bYNJ52WYre6gLMu4K+Ghd02og+ILgIio Q827h0spqIJYHrR3Ynnhxdlv5GPCobh+AKsQMdTIuCzR6JSCBk6GHkg33SiWScKMUzT8B/cn ypLfGnfV/LDZ9wS2TMzIlK/uv0Vd4C0OGDd/GCi5Gwu/Ot0aY7fzZo2CiRV+/nJBWPRRBTji bE4FG2rt7WSRLO/QmH2meIW4f0USDiHeNwznHkPei59vRdlMyQdsxrmgSRDuX9Y3UkERxbgd uscqC8Cpcy5kpF11EW91J8aGpcxASc+5Pa66/+7CrpBC2DnfcfACdMAje7yeMn9XlHrqXNlQ GaglEcnGN2qVqRcKgcjJX+ur8l56BVpBPFYQYkYkIdQAuhlPylxOvsMcqI6VoEWNt0iFF3dA //0MNb8fEqw5TlxDPOt6BDhDKowkxOGIA9LOcF4PkaR9Qkvwo2P4vA/8fhCnMqlSPom4xYdk Ev8P554zDoL/XMHl+s7A0MjIJzT253ejZKlWeO68pAbNy/z7QRn2lFDnjwkQwH6sKPchYl2f 0g//Yu3vDkqk8+mi2letP3XBl2hjv2eCZjTh34VvtgY5oeL2ROSJWNd18+7O6q3hECZ727EW gIb3LK9g4mKF6+Rch6Gwz1Y4fmC5554fd2Y2XbVzzz6AGUC6Y+ohNg7lTAVO4wu43+IyTB8u ip5rX/JDGFv7Y1sl6tQJKAVIKAJE+Z3Ncqh3doQr9wWHl0UiQYKbSR9HpH1lmC1C3EEbTpwK fUIpZd1eQNyNJl1jHsZZIBYFsAfVNH/u6lB1TU+9bSOsV5SepdIb88d0fm3oZ4KzjhRHLFQF RwNUNn3ha6x4fbxYcwbvu5ZCiiX6yRTPoage/LUNkgQNX2PtPcur6CdxK6Pqm8EAI7PmYLfN NY3y01XhKNRvaVZoH2FugfUkhsBITglTIpI+n6YU06nDAcbeINFo67TSE0iL6Pek5a6gUQQC 6w+hJCaMr8KYud0q3ccHyU3TlAPDe10En3GsVz7Y5Sa3ODGdbmkfjK8Af3ogGNBVmpV16Xl8 4rETFv7POSUB2eMtbpmBopd+wKqHCwUEy3fx1zDbM9mp+pcDoL73rRZmlgmNfW/4o4qBzxRf FYTQLE69wAFU2IFce9PjtUAlBdC+6r3X24h3uD+EC37s/vWhxuKj2glaU9ONrVJ/SPvlqXOO WR1Zqw57vHMKimLdG3c24l8PkSw1usudgAA5OyO5Ag0EWY4wyQEQAMVp0U38Le7d80Mu6AT+ 1dMes87iKn30TdMuLvSg2uYqJ1T2riRBF7zU6u74HF6zps0rPQviBXOgoSuKa1hnS6OwFb9x yQPlk76LY96SUB5jPWJ3fO78ZGSwkVbJFuG9gpD/41n8Unn1hXgDb2gUaxD0oXv/723EmTYC vSo3z6Y8A2aBQNr+PyhQAPDazvVQ+P7vnZYq1oK0w+D7aIix/Bp4mo4VbgAeAeMxXWSZs8N5 NQtXeTBgB7DqrfJP5wWwgCsROfeds6EoddcYgqhG0zVU9E54C8JcPOA0wKVs+9+gt2eyRNtx 0UhFbah7qXuJGhWy/0CLXvVoCoS+7qpWz070TBAlPZrg9D0o2gOw01trQgoKAYBKKgJhxaX/ 4gzi+5Ccm33LYH9lAVTdzdorejuV1xWdsnNyc8OAPeoXBf9RIIWfQVmbhVXBp2DAPjV6/kIJ Eml7MNJfEvqjV9zKsWF9AFlsqDWZDCyUdqR96ahTSD34pRwb6a9H99/GrjeowKaaL95DIVZT C6STvDNL6kpys4sOe2AMmQGv2MMcJB3aYLzH8f1sEQ9S0UMX7/6CifEG6JodG6Y/W/lLo1Vv DxeDA+u4Lgq6qxlksp8M78FjcmxFVlf4cpCi2ucbZxurhlBkjtZZ8MVAEde3hlqjcBl2Ah6Q D826FTxscOGlHEfNABEBAAGJAjwEGAEKACYCGwwWIQSofQA6zrItXEgHWTzAfqwo9yFiXQUC XEz31QUJBKaOuQAKCRDAfqwo9yFiXUvnEACBWe8wSnIvSX+9k4LxuLq6GQTOt+RNfliZQkCW 5lT3KL1IJyzzOm4x+/slHRBl8bF7KEZyOPinXQXyJ/vgIdgSYxDqoZ7YZn3SvuNe4aT6kGwL EYYEV8Ecj4ets15FR2jSUNnVv5YHWtZ7bP/oUzr2LT54fjRcstYxgwzoj8AREtHQ4EJWAWCO ZuEHTSm5clMFoi41CmG4DlJbzbo4YfilKYm69vwh50Y8WebcRN31jh0g8ufjOJnBldYYBLwN Obymhlfy/HKBDIbyCGBuwYoAkoJ6LR/cqzl/FuhwhuDocCGlXyYaJOwXgHaCvVXI3PLQPxWZ +vPsD+TSVHc9m/YWrOiYDnZn6aO0Uk1Zv/m9+BBkWAwsreLJ/evn3SsJV1omNBTITG+uxXcf JkgmmesIAw8mpI6EeLmReUJLasz8QkzhZIC7t5rGlQI94GQG3Jg2dC+kpaGWOaT5G4FVMcBj iR1nXfMxENVYnM5ag7mBZyD/kru5W1Uj34L6AFaDMXFPwedSCpzzqUiHb0f+nYkfOodf5xy0 46+3THy/NUS/ZZp/rI4F7Y77+MQPVg7vARfHHX1AxYUKfRVW5j88QUB70txn8Vgi1tDrOr4J eD+xr0CvIGa5lKqgQacQtGkpOpJ8zY4ObSvpNubey/qYUE3DCXD0n2Xxk4muTvqlkFpOYA== Message-ID: Date: Tue, 4 Jun 2019 14:38:59 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <5cf5a724.1c69fb81.1e8f0.08fb@mx.google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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=,,,,
[,
+][;,,,,
[,
+]+] >> >> Where, >> ::= The device name. >> ::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | "" >> ::= The device minor number | "" >> ::= "ro" | "rw" >>
::= >> ::= "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 or > > 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" Thanks > > 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. Thanks Helen From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 9EB427D2EF for ; Tue, 4 Jun 2019 19:21:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726211AbfFDTVX (ORCPT ); Tue, 4 Jun 2019 15:21:23 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:44130 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726179AbfFDTVX (ORCPT ); Tue, 4 Jun 2019 15:21:23 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id 7052C281D9F Message-ID: <9460817290d5846a34b81470b15ac36d88a08aad.camel@collabora.com> Subject: Re: [PATCH v12] dm: add support to directly boot to a mapped device From: Ezequiel Garcia To: Helen Koike , Stephen Boyd , dm-devel@redhat.com Cc: wad@chromium.org, keescook@chromium.org, snitzer@redhat.com, linux-doc@vger.kernel.org, richard.weinberger@gmail.com, linux-kernel@vger.kernel.org, linux-lvm@redhat.com, enric.balletbo@collabora.com, kernel@collabora.com, agk@redhat.com Date: Tue, 04 Jun 2019 16:21:10 -0300 In-Reply-To: References: <20190221203334.24504-1-helen.koike@collabora.com> <5cf5a724.1c69fb81.1e8f0.08fb@mx.google.com> Organization: Collabora Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Hi Stephen, On Tue, 2019-06-04 at 14:38 -0300, Helen Koike wrote: > 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=,,,,
[,
+][;,,,,
[,
+]+] > > > > > > Where, > > > ::= The device name. > > > ::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | "" > > > ::= The device minor number | "" > > > ::= "ro" | "rw" > > >
::= > > > ::= "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 or > > > > 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. > Thanks for bringing this up. Helen and I have been looking at this code, and we think it's possible to move things around and add some helpers, so we can implement rootwait behavior, without actually cluttering init/do_mounts.c. And along the way, we might get the chance to clean-up this code even further. Regards, Eze From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE,T_DKIMWL_WL_HIGH autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 269DC7D2EF for ; Tue, 4 Jun 2019 19:35:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726211AbfFDTfD (ORCPT ); Tue, 4 Jun 2019 15:35:03 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:42534 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725933AbfFDTfD (ORCPT ); Tue, 4 Jun 2019 15:35:03 -0400 Received: by mail-pg1-f195.google.com with SMTP id e6so9674696pgd.9 for ; Tue, 04 Jun 2019 12:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=message-id:mime-version:content-transfer-encoding:in-reply-to :references:cc:to:from:subject:user-agent:date; bh=xTD3XYO7Igxo0exyVWI6cc/41JrtEN9oQdvmNtmSfwE=; b=e65zpbS38buPRA7hJtKymGX9tOAOvBPPnprOcQ6P31L4GDzt+jIz0g3GAnaNu6GwrK hXlj+/nGYhqoWPwArQB6kpxB0vnmyu9pMLgzZCwXSQeWDJ4VaDBX6ebIrbJq4LqWNsil nyb5IFzRCjhcgcgLI1jmjaOzRFqzAy3rG/zw8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version :content-transfer-encoding:in-reply-to:references:cc:to:from:subject :user-agent:date; bh=xTD3XYO7Igxo0exyVWI6cc/41JrtEN9oQdvmNtmSfwE=; b=o5DcvLk9lFC0g5+ZcKVu9K0Kn5cRYcK+D5yUYCR4Ct4UINbR6sqYubadVEefta41Ng 8WGIpP8mbCUPekudcxuSnHujZGRyRuaJ0+YGUMPzoORDe+DEEXHBrXeAnGbgnwZ558gc wwuvJgKIAMLoXmzua5wDAr7foopMPVB4VTf2YXk+BKSaTtHDTtcMsFKvsjIO98IbALCt MxEdpb90P63bCaAEH/fNmPAt3RFNL3TxH1P8PTIwKlj6iJzR3rQjXCRU9iYerLab8C6i iq1emnzeU7/bZ/Nr/PVg/5ZnwVmSNhNdExiRvKC8ZtUlrqMG4vu5/u1HHEkXJjEMwtOy ADwg== X-Gm-Message-State: APjAAAXlrHd0+PEoaU6goY7LNwk9GUeBM2SrXiOAG8f22Tx/FMcOo7dX EqnAS5KzqWsWALA2QVSaUG0lhA== X-Google-Smtp-Source: APXvYqwy/fZXLgeDSXS8MB6n4hh9Ump+ILns1RyYBF25QdlYHm22iNJCOMA32625Bb8ggKG9bpa1gA== X-Received: by 2002:a63:70f:: with SMTP id 15mr237119pgh.432.1559676902860; Tue, 04 Jun 2019 12:35:02 -0700 (PDT) Received: from chromium.org ([2620:15c:202:1:fa53:7765:582b:82b9]) by smtp.gmail.com with ESMTPSA id g17sm29008667pfb.56.2019.06.04.12.35.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 04 Jun 2019 12:35:02 -0700 (PDT) Message-ID: <5cf6c7e6.1c69fb81.e1551.8ac4@mx.google.com> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20190221203334.24504-1-helen.koike@collabora.com> <5cf5a724.1c69fb81.1e8f0.08fb@mx.google.com> Cc: wad@chromium.org, keescook@chromium.org, snitzer@redhat.com, linux-doc@vger.kernel.org, richard.weinberger@gmail.com, linux-kernel@vger.kernel.org, linux-lvm@redhat.com, enric.balletbo@collabora.com, kernel@collabora.com, agk@redhat.com To: Helen Koike , dm-devel@redhat.com From: Stephen Boyd Subject: Re: [PATCH v12] dm: add support to directly boot to a mapped device User-Agent: alot/0.8.1 Date: Tue, 04 Jun 2019 12:35:01 -0700 Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Quoting Helen Koike (2019-06-04 10:38:59) > On 6/3/19 8:02 PM, Stephen Boyd wrote: > >=20 > > 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: > >=20 > > 1) rootwait isn't considered > >=20 > > 2) verity doesn't seem to accept UUID for or > >=20 > > 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. >=20 > 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. Alright, great. >=20 > >=20 > > 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=3D1) 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. >=20 > 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. >=20 Ok, thanks for pointing that out. Sorry I totally missed this codepath and I should have investigated more. It works for me with the PARTNROFF syntax that we've been using, so the problem is the rootwait stuff. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id C4A2B7D2F0 for ; Wed, 5 Jun 2019 08:36:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726604AbfFEIgB (ORCPT ); Wed, 5 Jun 2019 04:36:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42310 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726537AbfFEIgB (ORCPT ); Wed, 5 Jun 2019 04:36:01 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D65E830860BD; Wed, 5 Jun 2019 08:36:00 +0000 (UTC) Received: from [10.43.17.112] (unknown [10.43.17.112]) by smtp.corp.redhat.com (Postfix) with ESMTP id AFD045F7C2; Wed, 5 Jun 2019 08:35:50 +0000 (UTC) Subject: Re: [dm-devel] [PATCH v12] dm: add support to directly boot to a mapped device To: Stephen Boyd , Helen Koike , dm-devel@redhat.com Cc: wad@chromium.org, keescook@chromium.org, snitzer@redhat.com, linux-doc@vger.kernel.org, richard.weinberger@gmail.com, linux-kernel@vger.kernel.org, linux-lvm@redhat.com, enric.balletbo@collabora.com, kernel@collabora.com, agk@redhat.com References: <20190221203334.24504-1-helen.koike@collabora.com> <5cf5a724.1c69fb81.1e8f0.08fb@mx.google.com> <5cf6c7e6.1c69fb81.e1551.8ac4@mx.google.com> From: Zdenek Kabelac Organization: Red Hat Message-ID: Date: Wed, 5 Jun 2019 10:35:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <5cf6c7e6.1c69fb81.e1551.8ac4@mx.google.com> Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Wed, 05 Jun 2019 08:36:01 +0000 (UTC) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Dne 04. 06. 19 v 21:35 Stephen Boyd napsal(a): > Quoting Helen Koike (2019-06-04 10:38:59) >> On 6/3/19 8:02 PM, Stephen Boyd wrote: >>> >>> 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 or >>> >>> 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. > > Alright, great. > >> >>> >>> 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 Hi As not a direct dm developer - isn't this going a bit too far ? - This way you will need to soon move halve of the userspace functionality into kernel space. IMHO would be way more progressive to start using initramdisk and let userspace resolve all the issue. Clearly once you start to wait for some 'devices' to appear - then you will need to way for CORRECT device as well - since sda,sdb... goes in random order, so you would need to parse disk headers and so on. What you are effectively doing at this moment is you are shifting/ballooning 'ramdisk' code into kernel image - just to be named a kernel. So why it is so big deal to start to use ramdisk on ChromeOS? That would have solved most of problems you have or you will have instantly. Regards Zdenek