[OE-core] Solving a circular dependency issue between the main image and initramfs

Ayoub Zaki ayoub.zaki at embexus.com
Tue Mar 10 21:33:05 UTC 2020


Hi,


On 10.03.20 22:23, Bartosz Golaszewski wrote:
> 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?


I think that best thing is to implement the dm-verity stuffs as a wic 
plugin, check this example:


https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/scripts/lib/wic/plugins/source/dm-verity.py

> [1] https://github.com/brgl/meta-security/blob/topic/verity-et-al/classes/dm-verity-img.bbclass

Mit freundlichen Grüßen / Kind regards

-- 
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg


Mobile   : +4917662901545
Email    : ayoub.zaki at embexus.com
Homepage : https://embexus.com
VAT No.  : DE313902634



More information about the Openembedded-core mailing list