Re: [dm-devel] [PATCH v12] dm: add support to directly boot to a mapped device

2019-06-05 Thread Zdenek Kabelac

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


[dm-devel] [PATCH v12] dm: add support to directly boot to a mapped device

2019-02-22 Thread Helen Koike
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.
  ::= ---- | ""
 ::= 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 

Re: [dm-devel] [PATCH v12] dm: add support to directly boot to a mapped device

2019-02-21 Thread Kees Cook
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.
>   ::= ---- | ""
>  ::= 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

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel