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

[Ernst Sjöstrand]

Hi!

I have done something very similar, here's what I did.

My ramdisk is just a vanilla cpio.
My kernel is just vanilla zImage.

My main image does "inherit magic" and magic.bbclass does something like this, where create_custom_fitimage has a lot of kernel-fitimage.bbclass copied out.
do_magic () {
create_custom_fitimage
install fitImage.bin ${IMAGE_ROOTFS}/boot/fitImage
}
do_magic[depends] += "my-ramdisk:do_image_complete  virtual/kernel"
addtask magic before do_image after do_pre_image_task

It does read a lot of stuff from deploy but so does the main kernel-fitimage.bbclass so I don't think that's a problem.

Regards
//Ernst

On Tue, 2020-03-10 at 22:23 +0100, 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?


Best regards,

Bartosz Golaszewski


[1] https://urldefense.com/v3/__https://github.com/brgl/meta-security/blob/topic/verity-et-al/classes/dm-verity-img.bbclass__;!!BFCLnRDDbM3FOmw!txpeOwM3etV4NJvGfflIsSW7V8RsvhhLNrDSJLj0iliKoiEm8Iu2Tf0NDsJyJVDxIcZFIg$

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20200316/b207705f/attachment.html>