[2/4] boot: fit: support generating DM verity cmdline parameters

[Simon Glass]

Hi Daniel,

On 2026-04-02T03:08:27, Daniel Golle <daniel at makrotopia.org> wrote:
> boot: fit: support generating DM verity cmdline parameters
> boot: fit: support generating DM verity cmdline parameters
>
> Add fit_verity_build_cmdline(): when a FILESYSTEM loadable carries a
> dm-verity subnode, construct the dm-mod.create= kernel cmdline parameter
> from the verity metadata (block-size, data-blocks, algo, root-hash,
> salt) and append it to bootargs.
>
> Also add dm-mod.waitfor=/dev/fit0[,/dev/fitN] for each dm-verity device
> so the kernel waits for the underlying FIT block device to appear before
> setting up device-mapper targets. This is needed when the block driver
> probes late, e.g. because it depends on NVMEM calibration data.
>
> The dm-verity target references /dev/fitN where N is the loadable's
> index in the configuration -- matching the order Linux's FIT block
> driver assigns block devices.  hash-start-block is read directly from
> the FIT dm-verity node; mkimage ensures its value equals num-data-blocks
> by invoking veritysetup with --no-superblock.
>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>

> diff --git a/boot/Kconfig b/boot/Kconfig
> @@ -142,6 +142,27 @@ config FIT_CIPHER
> +config FIT_VERITY
> +     ...
> +       and BOOTSTD bootmeths.
> +
> +

Drop extra blank line.

> diff --git a/boot/image-fit.c b/boot/image-fit.c
> @@ -2642,3 +2682,299 @@ out:
> +     if (!data_block_size || data_block_size < 512 ||
> +         !hash_block_size || hash_block_size < 512 ||
> +         !num_data_blocks)
> +             return -EINVAL;

dm-verity requires block sizes to be a power of two (and divisible by
512). The first check `!data_block_size` is redundant given the `<
512` check that follows. Please can you add a power-of-two validation
using is_power_of_2() from <linux/log2.h>? Otherwise the kernel will
likely reject the table at boot time with a confusing error.

> diff --git a/boot/image-fit.c b/boot/image-fit.c
> @@ -2642,3 +2682,299 @@ out:
> +int fit_verity_build_cmdline(const void *fit, int conf_noffset,
> +                          struct bootm_headers *images)
> +{
> +     ...
> +     if (found) {
> +             /* Transfer ownership to the bootm_headers */
> +             images->dm_mod_create = dm_create;
> +             images->dm_mod_waitfor = dm_waitfor;
> +     } else {
> +             free(dm_create);
> +             free(dm_waitfor);
> +     }
> +
> +     return found;

When found > 0, this returns a positive value which could be confused
with an error by callers that only check `< 0`. The call site in
boot_get_loadable() does `if (fit_img_result < 0) return
fit_img_result;` so it works, but I suspect returning 0 for success
and keeping the count internal would be cleaner.  What do you think?

> diff --git a/boot/bootm.c b/boot/bootm.c
> @@ -242,6 +242,7 @@ static int boot_get_kernel(...)
> static int bootm_start(void)
> {
> +     fit_verity_free(&images);
>       memset((void *)&images, 0, sizeof(images));

Just to check: fit_verity_free() is called here before memset(), which
means the pointers must already be valid (or NULL) from a prior boot
attempt. This works because fit_verity_free() checks for NULL
internally, and .bss is zeroed. How about a comment explaining the
ordering?

Regards,
Simon