Re: Solving a circular dependency issue between the main image and initramfs

[Bartosz Golaszewski <brgl@bgdev.pl>]

wt., 10 mar 2020 o 22:23 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>
> Hi,
>
> I've been struggling for a while now trying to fix a circular
> dependency issue when the initramfs image needs to access an image
> file generated by the main (for lack of a better term) image recipe.
>
> I've tried to fix our downstream layer only to come to the conclusion
> that some things must probably be modified upstream to make sense.
> Unfortunately when trying different solutions I always arrive at some
> kind of circular dependency with the current task order.
>
> My use-case is the following:
>
> I'd like to use dm-verity to protect the rootfs from tampering as part
> of the verified boot flow. At boot-time the rootfs partition is mapped
> using veritysetup from a trusted initramfs stored in a signed
> fitImage. This initramfs also contains the root verity hash while the
> rest of the hash tree is stored on a different partition.
>
> The dm-verity meta data is generated from a class[1] I wrote with the
> aim of upstreaming it to meta-security as an image conversion of
> ext[234] and btrfs images.
>
> For the sake of clarity of the example let's assume we're generating
> an ext4 image for core-image-full-cmdline and set INITRAMFS_IMAGE to
> "dm-verity-image-initramfs".
>
> The veritysetup conversion becomes part of the
> core-image-full-cmdline:do_image_ext4 task, while
> dm-verity-image-initramfs:do_rootfs needs to depend on
> core-image-full-cmdline:do_image_ext4 as it needs to compute the
> hashes based on the block device image. It cannot however depend on
> core-image-full-cmdline:do_image_complete as it depends on many tasks
> (e.g. kernel and u-boot tasks) that would inevitably lead to a
> circular dependency.
>
> The output files from recipes inheriting image.bbclass are not
> deployed before do_image_complete nor is anything done in do_install
> or do_populate_sysroot (these tasks are flagged noexec or deleted), so
> I cannot access them from dm-verity-image-initramfs:do_rootfs.
>
> As a workaround in the downstream layer I've been manually putting the
> verity meta data into the DEPLOY_DIR_IMAGE from
> core-image-full-cmdline:do_image_ext4 but this obviously isn't correct
> as far as the deploy class and sstate are concerned.
>
> Now the question is: how do I approach it so that I can eventually
> make it part of upstream meta-security?
>
> Do I implement do_install in image.bbclass so that initramfs can
> depend on core-image-full-cmdline:do_populate_sysroot and have the
> artifacts installed locally? But this would mean that the initramfs
> recipe deploys the main image artifact. Should we deploy the images
> earlier (before do_image_complete) for the initramfs recipe to fetch
> from DEPLOY_DIR_IMAGE? Any other ideas?
>
> Best regards,
> Bartosz Golaszewski
>
> [1] https://github.com/brgl/meta-security/blob/topic/verity-et-al/classes/dm-verity-img.bbclass

There has been no relevant feedback, but I've been experimenting with
various things. I think that the best approach would be to make image
artifacts installable into dependant recipes' sysroots (in
/usr/share/images/). This way the initramfs recipe could calculate the
dm-verity hashes from the resulting ext4 image before it gets
deployed. We could also modify the kernel recipe to not fetch the
initramfs image from the shared directory but instead have it
installed in its sysroot.

For this I tried to re-enable the do_install task in image.bbclass.
Unfortunately either I'm doing something wrong or standard tasks are
subject to different rules when it comes to dependencies. I've been so
far unable to make do_install depend on any image tasks (i.e. make
do_install depend on do_image_ext4/wic etc.) no matter if I use
do_install[depends] or addtask or appropriate helpers from python.
Unfortunately I've been unable to find any information on that in the
manual.

Is there some trick to changing the dependencies of standard tasks?

Bartosz