* Solving a circular dependency issue between the main image and initramfs @ 2020-03-10 21:23 Bartosz Golaszewski 2020-03-10 21:33 ` Ayoub Zaki ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Bartosz Golaszewski @ 2020-03-10 21:23 UTC (permalink / raw) To: Patches and discussions about the oe-core layer, Armin Kuster, Khem Raj, Richard Purdie Cc: Guillaume Pain, Jerome Neanne 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solving a circular dependency issue between the main image and initramfs 2020-03-10 21:23 Solving a circular dependency issue between the main image and initramfs Bartosz Golaszewski @ 2020-03-10 21:33 ` Ayoub Zaki 2020-03-10 22:02 ` Bartosz Golaszewski 2020-03-16 10:48 ` Bartosz Golaszewski 2020-03-16 14:02 ` Ernst Sjöstrand 2 siblings, 1 reply; 12+ messages in thread From: Ayoub Zaki @ 2020-03-10 21:33 UTC (permalink / raw) To: openembedded-core 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@embexus.com Homepage : https://embexus.com VAT No. : DE313902634 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solving a circular dependency issue between the main image and initramfs 2020-03-10 21:33 ` Ayoub Zaki @ 2020-03-10 22:02 ` Bartosz Golaszewski 2020-03-10 22:54 ` Ayoub Zaki 0 siblings, 1 reply; 12+ messages in thread From: Bartosz Golaszewski @ 2020-03-10 22:02 UTC (permalink / raw) To: Ayoub Zaki; +Cc: Patches and discussions about the oe-core layer wt., 10 mar 2020 o 22:33 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a): > > > > > 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 > This doesn't look like a correct solution. For starters: not every platform uses wic. The platform I'm aiming this at uses fastboot and requires separate images for each partition. This plugin also seems to be unnecessarily complicated with additional signature for the verity hash tree. This is not needed as long as the root hash comes from a secure place - which it does in my case: the fitImage containing the initramfs is signed and the key is appended to u-boot's DTB. When do_image_wic starts, u-boot and initramfs assembly are long completed - another reason for not using a wic plugin. Best regards, Bartosz Golaszewski ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solving a circular dependency issue between the main image and initramfs 2020-03-10 22:02 ` Bartosz Golaszewski @ 2020-03-10 22:54 ` Ayoub Zaki 2020-03-11 8:03 ` Bartosz Golaszewski 0 siblings, 1 reply; 12+ messages in thread From: Ayoub Zaki @ 2020-03-10 22:54 UTC (permalink / raw) To: Bartosz Golaszewski; +Cc: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 2269 bytes --] On 10.03.20 23:02, Bartosz Golaszewski wrote: > wt., 10 mar 2020 o 22:33 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a): >>> 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 >> > This doesn't look like a correct solution. For starters: not every > platform uses wic. The platform I'm aiming this at uses fastboot and > requires separate images for each partition. My proposition was refering to your example : https://github.com/brgl/meta-security/commit/83c8e8fba6988249c9d351aa2ad6e02a71b010df#diff-33f7c29b373860ec45379a5f2dc42a75 your are trying to include the dm-verity conversion output to your wic wks using the following: part / --source rawcopy --ondisk mmcblk --sourceparams="file=${IMGDEPLOYDIR}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_TYPE}" In this case you will definitely stuck in a circular dependency unless using a Wic plugin. > > This plugin also seems to be unnecessarily complicated with additional > signature for the verity hash tree. This is not needed as long as the > root hash comes from a secure place - which it does in my case: the > fitImage containing the initramfs is signed and the key is appended to > u-boot's DTB. When do_image_wic starts, u-boot and initramfs assembly > are long completed - another reason for not using a wic plugin. I was referring to the plugin not the implementation which does not work anyway... Mit freundlichen Grüßen / Kind regards -- Ayoub Zaki Embedded Systems Consultant Vaihinger Straße 2/1 D-71634 Ludwigsburg Mobile : +4917662901545 Email : ayoub.zaki@embexus.com Homepage : https://embexus.com VAT No. : DE313902634 [-- Attachment #2: Type: text/html, Size: 4178 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solving a circular dependency issue between the main image and initramfs 2020-03-10 22:54 ` Ayoub Zaki @ 2020-03-11 8:03 ` Bartosz Golaszewski 0 siblings, 0 replies; 12+ messages in thread From: Bartosz Golaszewski @ 2020-03-11 8:03 UTC (permalink / raw) To: Ayoub Zaki; +Cc: Patches and discussions about the oe-core layer wt., 10 mar 2020 o 23:54 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a): > > > On 10.03.20 23:02, Bartosz Golaszewski wrote: > > wt., 10 mar 2020 o 22:33 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a): > > 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 > > This doesn't look like a correct solution. For starters: not every > platform uses wic. The platform I'm aiming this at uses fastboot and > requires separate images for each partition. > > > My proposition was refering to your example : > The example is there just to include support for one of the reference boards - BBB in this case. The initramfs itself as well as the rest should be generic though. > > https://github.com/brgl/meta-security/commit/83c8e8fba6988249c9d351aa2ad6e02a71b010df#diff-33f7c29b373860ec45379a5f2dc42a75 > > > your are trying to include the dm-verity conversion output to your wic wks using the following: > > > part / --source rawcopy --ondisk mmcblk --sourceparams="file=${IMGDEPLOYDIR}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_TYPE}" > > > In this case you will definitely stuck in a circular dependency unless using a Wic plugin. > Actually this isn't a problem. The dm-verity class makes do_image_wic depend on do_image_ext[234] and do_image_btrfs and since do_image_wic is part of the same recipe, we can fetch the image from IMGDEPLOYDIR before it's deployed. Best regards, Bartosz Golaszewski ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solving a circular dependency issue between the main image and initramfs 2020-03-10 21:23 Solving a circular dependency issue between the main image and initramfs Bartosz Golaszewski 2020-03-10 21:33 ` Ayoub Zaki @ 2020-03-16 10:48 ` Bartosz Golaszewski 2020-03-16 11:01 ` Richard Purdie 2020-03-16 14:02 ` Ernst Sjöstrand 2 siblings, 1 reply; 12+ messages in thread From: Bartosz Golaszewski @ 2020-03-16 10:48 UTC (permalink / raw) To: Patches and discussions about the oe-core layer, Armin Kuster, Khem Raj, Richard Purdie Cc: Guillaume Pain, Jerome Neanne 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solving a circular dependency issue between the main image and initramfs 2020-03-16 10:48 ` Bartosz Golaszewski @ 2020-03-16 11:01 ` Richard Purdie 2020-03-17 13:26 ` Bartosz Golaszewski 0 siblings, 1 reply; 12+ messages in thread From: Richard Purdie @ 2020-03-16 11:01 UTC (permalink / raw) To: Bartosz Golaszewski, Patches and discussions about the oe-core layer, Armin Kuster, Khem Raj Cc: Guillaume Pain, Jerome Neanne On Mon, 2020-03-16 at 11:48 +0100, Bartosz Golaszewski wrote: > 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? I don't know how exactly you're configuring the system but it should be possible to have the main rootfs built first, adding in the signing, then have the initramfs depend on that. I can understand some circular dependencies could creep in as many configurations have the initramfs as part of the main image but if you don't configure that, you shouldn't see those dependencies. I do fear your "re-enable" do_install route isn't going to get you where you want to be. Can you give a simple example of how you reproduce the circular dependencies with standard poky or oe-core? That might let others give comment more easily. Cheers, Richard ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solving a circular dependency issue between the main image and initramfs 2020-03-16 11:01 ` Richard Purdie @ 2020-03-17 13:26 ` Bartosz Golaszewski 2020-03-17 13:45 ` Quentin Schulz 0 siblings, 1 reply; 12+ messages in thread From: Bartosz Golaszewski @ 2020-03-17 13:26 UTC (permalink / raw) To: Richard Purdie Cc: Guillaume Pain, Jerome Neanne, Patches and discussions about the oe-core layer pon., 16 mar 2020 o 12:01 Richard Purdie <richard.purdie@linuxfoundation.org> napisał(a): > > On Mon, 2020-03-16 at 11:48 +0100, Bartosz Golaszewski wrote: > > 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? > > I don't know how exactly you're configuring the system but it should be > possible to have the main rootfs built first, adding in the signing, > then have the initramfs depend on that. > I too thought this should be possible with current implementation and yet I've spent so many hours on this to no avail it's not funny. :( > I can understand some circular dependencies could creep in as many > configurations have the initramfs as part of the main image but if you > don't configure that, you shouldn't see those dependencies. > I think there are more problems with this and the main reason is the fact that wic is just a regular image type. I'd argue it should be its own recipe since it can fetch deployed files from multiple recipes (including different images - for instance if we wanted to build a special recovery image that would need to include the main image + minimal rootfs). First: the initramfs recipe needs to access an artifact generated by do_image_ext4 from the main image. If we're not running do_install from image.bbclass (which we currently don't), this can only happen after do_image_complete which does the sstate deployment. So initramfs.do_image_ext4 depends on rootfs.do_image_complete. Next the kernel bbclass needs the initramfs image to assemble the fitimage - so kernel.do_assemble_fitimage_initramfs depends on initramfs.do_image_complete. Next we have the inter-dependencies between the kernel and u-boot because we need to sign the fitImage for dm-verity to make sense. Currently u-boot.do_build depends on kernel.do_deploy. And then the culprit: rootfs.do_image_wic needs to fetch the boot files so it depends on u-boot.do_deploy but rootfs.do_image_complete runs after rootfs.do_image_wic. I guess if we made wic a separate recipe - not just an image type, it could help here. > I do fear your "re-enable" do_install route isn't going to get you > where you want to be. > Why not? This is what currently happens with the dependencies between fitimage <-> u-boot when UBOOT_SIGN_ENABLE is set to "1". U-boot installs the DTB image - that would normally be deployed - into the /usr/share directory of kernel's sysroot. > Can you give a simple example of how you reproduce the circular > dependencies with standard poky or oe-core? That might let others give > comment more easily. > It's very simple: add an initramfs to the recipe (INITRAMFS_IMAGE = "some-image") and add the following to some-image.bb recipe: do_rootfs[depends] += "core-image-minimal:do_image_complete" with the assumption that you're building core-image-minimal. You also need "wic" in IMAGE_FSTYPES. Best regards, Bartosz Golaszewski ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solving a circular dependency issue between the main image and initramfs 2020-03-17 13:26 ` Bartosz Golaszewski @ 2020-03-17 13:45 ` Quentin Schulz 2020-03-17 14:12 ` Bartosz Golaszewski 0 siblings, 1 reply; 12+ messages in thread From: Quentin Schulz @ 2020-03-17 13:45 UTC (permalink / raw) To: Bartosz Golaszewski Cc: Guillaume Pain, Jerome Neanne, Patches and discussions about the oe-core layer Hi Bartosz, On Tue, Mar 17, 2020 at 02:26:37PM +0100, Bartosz Golaszewski wrote: > pon., 16 mar 2020 o 12:01 Richard Purdie > <richard.purdie@linuxfoundation.org> napisał(a): > > > > On Mon, 2020-03-16 at 11:48 +0100, Bartosz Golaszewski wrote: > > > 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? > > > > I don't know how exactly you're configuring the system but it should be > > possible to have the main rootfs built first, adding in the signing, > > then have the initramfs depend on that. > > > > I too thought this should be possible with current implementation and > yet I've spent so many hours on this to no avail it's not funny. :( > I haven't read carefully your thread but ran into what seems to be a similar situation two years ago: https://youtu.be/jtLQ8SzfrDU?t=2336 So, TL;DR, couldn't create a fitimage with kernel-fitimage because of circular dependencies and we had to create a new fitimage bbclass which wasn't inherited in the kernel but by the image recipe IIRC. I didn't think at that time kernel-fitimage made sense because you can technically put whatever you want in a fitimage. I can technically not have a kernel in it. I thought a fitimage bbclass inherited by an image recipe made much more sense. It was two years ago, didn't share anything with the YP folks back then, so my bad. I haven't had this issue since then (no product requiring this) so didn't think much more about it :/ I promised once we had something good enough we would give back to the community. Now that I've left that company and forgot to do it, you can throw rocks at me. Good luck and keep us posted please. Quentin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solving a circular dependency issue between the main image and initramfs 2020-03-17 13:45 ` Quentin Schulz @ 2020-03-17 14:12 ` Bartosz Golaszewski 0 siblings, 0 replies; 12+ messages in thread From: Bartosz Golaszewski @ 2020-03-17 14:12 UTC (permalink / raw) To: Quentin Schulz, Richard Purdie, Khem Raj, Armin Kuster Cc: Guillaume Pain, Jerome Neanne, Patches and discussions about the oe-core layer wt., 17 mar 2020 o 14:45 Quentin Schulz <quentin.schulz@streamunlimited.com> napisał(a): > > Hi Bartosz, > > On Tue, Mar 17, 2020 at 02:26:37PM +0100, Bartosz Golaszewski wrote: > > pon., 16 mar 2020 o 12:01 Richard Purdie > > <richard.purdie@linuxfoundation.org> napisał(a): > > > > > > On Mon, 2020-03-16 at 11:48 +0100, Bartosz Golaszewski wrote: > > > > 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? > > > > > > I don't know how exactly you're configuring the system but it should be > > > possible to have the main rootfs built first, adding in the signing, > > > then have the initramfs depend on that. > > > > > > > I too thought this should be possible with current implementation and > > yet I've spent so many hours on this to no avail it's not funny. :( > > > > I haven't read carefully your thread but ran into what seems to be a > similar situation two years ago: > > https://youtu.be/jtLQ8SzfrDU?t=2336 > > So, TL;DR, couldn't create a fitimage with kernel-fitimage because of > circular dependencies and we had to create a new fitimage bbclass which > wasn't inherited in the kernel but by the image recipe IIRC. > > I didn't think at that time kernel-fitimage made sense because you can > technically put whatever you want in a fitimage. I can technically not > have a kernel in it. I thought a fitimage bbclass inherited by an image > recipe made much more sense. It was two years ago, didn't share anything > with the YP folks back then, so my bad. I haven't had this issue since > then (no product requiring this) so didn't think much more about it :/ > > I promised once we had something good enough we would give back to the > community. Now that I've left that company and forgot to do it, you can > throw rocks at me. > > Good luck and keep us posted please. > Quentin Thanks Quentin, this is pretty much what Ernst suggested earlier in this thread too. I'm not a fan of this solution. Richard et al: do you think making the fitimage class something an image recipe could inherit is a good idea? So far I think there are three solutions to the problem: 1. Make wic image a separate recipe that could run after everything else is done and deployed. 2. Make image.bbclass install its artifacts into whatever recipe DEPENDS on it. 3. Make fitimage a bbclass that could be added to IMAGE_CLASSES. Bartosz ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solving a circular dependency issue between the main image and initramfs 2020-03-10 21:23 Solving a circular dependency issue between the main image and initramfs Bartosz Golaszewski 2020-03-10 21:33 ` Ayoub Zaki 2020-03-16 10:48 ` Bartosz Golaszewski @ 2020-03-16 14:02 ` Ernst Sjöstrand 2020-03-17 14:05 ` Bartosz Golaszewski 2 siblings, 1 reply; 12+ messages in thread From: Ernst Sjöstrand @ 2020-03-16 14:02 UTC (permalink / raw) To: brgl, openembedded-core, richard.purdie, akuster808, raj.khem Cc: gpain, jneanne [-- Attachment #1: Type: text/plain, Size: 3730 bytes --] 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$ [-- Attachment #2: Type: text/html, Size: 5198 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solving a circular dependency issue between the main image and initramfs 2020-03-16 14:02 ` Ernst Sjöstrand @ 2020-03-17 14:05 ` Bartosz Golaszewski 0 siblings, 0 replies; 12+ messages in thread From: Bartosz Golaszewski @ 2020-03-17 14:05 UTC (permalink / raw) To: Ernst Sjöstrand; +Cc: jneanne, openembedded-core, gpain pon., 16 mar 2020 o 15:03 Ernst Sjöstrand <ernst.sjostrand@verisure.com> napisał(a): > > 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 > There are probably many workarounds for this, but if we can't do this with upstream OE-core then something is broken/missing upstream and we should fix it. This is what I'm trying to do. I'm just looking for the right way. I don't want to carry some non-upstreamable workaround over to every other project I'm working on - optimally this should be made part of OE-core/meta-security. Best regards, Bartosz Golaszewski ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-03-17 14:12 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-10 21:23 Solving a circular dependency issue between the main image and initramfs Bartosz Golaszewski 2020-03-10 21:33 ` Ayoub Zaki 2020-03-10 22:02 ` Bartosz Golaszewski 2020-03-10 22:54 ` Ayoub Zaki 2020-03-11 8:03 ` Bartosz Golaszewski 2020-03-16 10:48 ` Bartosz Golaszewski 2020-03-16 11:01 ` Richard Purdie 2020-03-17 13:26 ` Bartosz Golaszewski 2020-03-17 13:45 ` Quentin Schulz 2020-03-17 14:12 ` Bartosz Golaszewski 2020-03-16 14:02 ` Ernst Sjöstrand 2020-03-17 14:05 ` Bartosz Golaszewski
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.