linux-kernel - Re: dm-verity: How to exactly use the dm-mod.create with verity-metadata append

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]

Message-ID: <CAAFS_9G_gQrBBJ2AWpwBWwZK41qiaFhBXy17XDeL7hOBxOvFeQ@mail.gmail.com>
Date:   Tue, 23 Nov 2021 10:43:15 -0600
From:   Will Drewry <wad@...omium.org>
To:     Pintu Agarwal <pintu.ping@...il.com>
Cc:     dm-devel@...hat.com, helen.koike@...labora.com,
        Kees Cook <keescook@...omium.org>,
        enric.balletbo@...labora.com, snitzer@...hat.com, agk@...hat.com,
        open list <linux-kernel@...r.kernel.org>,
        Kernelnewbies <kernelnewbies@...nelnewbies.org>
Subject: Re: dm-verity: How to exactly use the dm-mod.create with
 verity-metadata append

On Tue, Nov 23, 2021 at 4:36 AM Pintu Agarwal <pintu.ping@...il.com> wrote:
>
> Hi,
>
> For rootfs dm-verity I am trying to pass dm-mod.create from our
> bootloader but it seems not working for me.
> So, I need some guidance on the parameters that we pass here.
> The documentation also does not seem to help much.
>
> Kernel: 4.14 (with dm-init patch backported)
> Target: Arm-32 / NAND / Simple Busybox / Bootloader (edk2)
> Build: Ubuntu-18.04 / Yocto 2.6
>
> Steps I followed:
> 1) First I am trying to generate the root hash for our rootfs using
> the veritysetup command:
> $ ls -l system.img
> 64172032 ==> IMAGE_SIZE
> $ veritysetup format system.img dm-init-verity.img
> UUID:                   eca62b73-b66a-4249-834b-471e83fc382c
> Hash type:              1
> Data blocks:            15667
> Data block size:        4096
> Hash block size:        4096
> Hash algorithm:         sha256
> Salt:
> 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b
> Root hash:
> 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af
>
> 2) Then I am trying to append the verity with the system image itself:
> $ cat dm-init-verity.img >> system.img
>
> 3) After that I am trying to pass dm-mod.create parameter like this:
> dm-mod.create=\"system,,,ro, 0 IMAGE_SIZE/512 verity 1
> /dev/ubiblock0_0 /dev/ubiblock0_0 4096 4096 DATA_BLOCKS 1 sha256
> 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af
> 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b\"
>
> 4) The Kernel command line seems to be updated properly:
> [    0.000000] Kernel command line:.. rootfstype=squashfs
> ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/ubiblock0_0
> dm-mod.create="system,,,ro, 0 125336 verity 1 /dev/ubiblock0_0
> /dev/ubiblock0_0 4096 4096 15667 1 sha256
> 10d9036f6efdd48dd49f09c8ece016a36a2c4d9a01a1f77f01485c65cf0e78af
> 8b66f42c07f576429109cf4e5d12ec072b23d242a9e653ac3423e49647339f5b" ....
>
> But it does not seem to work as expected.
> It gives below errors:
> ....
> [    4.747708] block ubiblock0_0: created from ubi0:0(system)
> [    4.752313] device-mapper: init: waiting for all devices to be
> available before creating mapped devices
> [    4.752313]
> [    4.766061] device-mapper: verity: sha256 using implementation
> "sha256-generic"
> [    4.776178] device-mapper: ioctl: dm-0 (system) is ready
> [    4.848886] md: Skipping autodetection of RAID arrays.
> (raid=autodetect will force)
> [    4.849288] VFS: Cannot open root device "ubiblock0_0" or
> unknown-block(252,0): error -16

I'd start with changing your root device to point to the device mapper
one you've just created.  E.g., root=/dev/dm-0  Then see how it goes
from there.

> ....
>
> I followed almost the same example from dm-init document:
> "verity":
>   dm-verity,,4,ro,
>     0 1638400 verity 1 8:1 8:2 4096 4096 204800 1 sha256
>     fb1a5a0f00deb908d8b53cb270858975e76cf64105d412ce764225d53b8f3cfd
>     51934789604d1b92399c52e7cb149d1b3a1b74bbbcb103b2a0aaacbed5c08584
>
> But this seems only refer to system and verity on a different blocks.
> I am not sure what parameter should be changed if my verity metadata
> is part of system image itself.
> Also, I don't know how 1638400;204800;1 is calculated here based on image size ?

It's the range of sectors covered by the device 0 to size_in_sectors:
  (data_blocks * block_size)/sector_size
  (15667 * 4096)/512
  125336
which you have in your entry already.

> So, people who have made this working successfully, please share the
> correct parameter to be used for the same block device.

hth,
will