From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay4-3.pub.mailoutpod1-cph3.one.com (mailrelay4-3.pub.mailoutpod1-cph3.one.com [46.30.212.13]) by mail.openembedded.org (Postfix) with ESMTP id 566276114E for ; Tue, 10 Mar 2020 21:33:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embexus.com; s=20191106; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:to:subject:from; bh=dJyy5t8dt0e1zrsab4/JAdpu907pOJKr3Yospdp29aM=; b=KG/OO+7LRRfeo61FCDd8qF22ZuUbDZvTU6sQT+v4ZGxN2+tF9DgHa3s/OumEDtGYOiYyRNl7Vys71 1yYFCSpDFqIbxS9Mu0+eLigm62Vl5dDA634RfN5pz4pn0XSoQOlmGs48ZThVoXWVldyD42CtiohM63 Crx8pZeRCeuMhqCdlQxKa7mJpqJUyI+xA93rushDNB3N+ASUqHjEO+RDS/j/UArFKO7HTWD+XAvTcx NVECFD7koiDg5DQIQfFHaKfjJlLi7/Met4JVjzP1hl5xB1iiBHOwaYleFU3OnOAyr19hjtp5i99/mQ NiiGPWacBZQAP9hOE2U2Rzf8nqCV7jA== X-HalOne-Cookie: e3822699196b181391f4e23dcf0c9c2b8e74e616 X-HalOne-ID: ba7fdb9c-6316-11ea-8c79-d0431ea8bb10 Received: from [192.168.178.22] (x4db4211c.dyn.telefonica.de [77.180.33.28]) by mailrelay4.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id ba7fdb9c-6316-11ea-8c79-d0431ea8bb10; Tue, 10 Mar 2020 21:33:06 +0000 (UTC) To: openembedded-core@lists.openembedded.org References: From: Ayoub Zaki Message-ID: Date: Tue, 10 Mar 2020 22:33:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Subject: Re: Solving a circular dependency issue between the main image and initramfs X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 21:33:06 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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