All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ayoub Zaki <ayoub.zaki@embexus.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: Solving a circular dependency issue between the main image and initramfs
Date: Tue, 10 Mar 2020 22:33:05 +0100	[thread overview]
Message-ID: <a571c00e-5c90-462b-2402-d82b5f0b8cf9@embexus.com> (raw)
In-Reply-To: <CAMRc=Mf_Ld80=Egf3jPBGYoGGZScSG3JHKL7cVArLihJSC8P0g@mail.gmail.com>

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



  reply	other threads:[~2020-03-10 21:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a571c00e-5c90-462b-2402-d82b5f0b8cf9@embexus.com \
    --to=ayoub.zaki@embexus.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.