Solving a circular dependency issue between the main image and initramfs

Solving a circular dependency issue between the main image and initramfs

[Bartosz Golaszewski]

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

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

[Ayoub Zaki]

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

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

[Bartosz Golaszewski]

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

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

[Ayoub Zaki]

[-- 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 --]

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

[Bartosz Golaszewski]

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

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

[Bartosz Golaszewski]

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

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

[Richard Purdie]

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

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

[Ernst Sjöstrand]

[-- 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 --]

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

[Bartosz Golaszewski]

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

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

[Quentin Schulz]

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

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

[Bartosz Golaszewski]

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

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

[Bartosz Golaszewski]

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