From: Mikko Rapeli <mikko.rapeli@linaro.org>
To: yocto@lists.yoctoproject.org, f.louveau@lacroix.group
Subject: Re: [yocto] Verity hash in kernel bootscript
Date: Thu, 2 May 2024 13:34:30 +0300 [thread overview]
Message-ID: <ZjNsNn2VVy366tjU@nuoska> (raw)
In-Reply-To: <pS1t.1714642083190660050.4DTn@lists.yoctoproject.org>
Hi,
On Thu, May 02, 2024 at 02:28:03AM -0700, f.louveau via lists.yoctoproject.org wrote:
> Hello,
>
> I have a project where I want to implement dm-verity on my rootfs (no initramfs here).
>
> I modify image recipe to split rootfs in multiple partition (weird this is not supported upstream).
> I generate rootfs as a squashfs with verity has table at the end.
> I also obtain a verity.env file as output in ${TMPDIR}/work-shared/${MACHINE}/dm-verity/
>
> My idea is to convert verity.env into a bootscript and inject it inside fitimage using UBOOT_ENV variable.
>
> My issue is the overall dependency. I need my rootfs before creating my bootfs (/boot) containing my fitimage.
>
> Ideally I want to
>
> * generate a first rootfs without uboot and fitimage (not possible as it is defined using KERNEL_IMAGETYPES).
> * convert verity.env into bootscript.txt and configure UBOOT_ENV
> * generate fitimage and create my bootfs
>
> I explore several ideas like multiconfig without success, multiple images (works but recompile several elements twice, not perfect), define new fstype or image (no success for now)
>
> Any advice or suggestion are welcomed.
>
> Additional question: why UBOOT_ENV is linked to UBOOT as it is only generated in u-boot recipe and then injected in do_assemble_fitimage. Maybe an independent recipe could be simpler.
I don't have direct answers to your problem but I had a somewhat similar problem.
In my case, I wanted to convert an existing .wic image recipe and initramfs to
create a .wic image with a dm-verity partition. In the end I had to split the
dm-verity rootfs (or actually just /usr) partition creation to a separate recipe
from the .wic image recipe. I was not able to order the image processing steps
correctly without this when using meta-security and dm-verity-img.bbclass.
Then in the initramfs recipe I switched to using uki binaries and uki.bbclass
which is based on changes posted to poky but needed a bunch of modifications to
work. For example to pick the kernel cmdline arguments from dm-verity-img.bbclass
output. Trying to upstream these bits together with some testing setup using qemu
(but missing an efi compatible machine currently).
So multiple image recipes for the different stages may be an option for your
case as well. I don't see why the different images would need to recompile
binaries differently. They should all use the same machine and distro
configuration.
Cheers,
-Mikko
next prev parent reply other threads:[~2024-05-02 10:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-02 9:28 Verity hash in kernel bootscript f.louveau
2024-05-02 10:34 ` Mikko Rapeli [this message]
2024-05-02 12:11 ` [yocto] " f.louveau
2024-05-06 8:07 ` f.louveau
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=ZjNsNn2VVy366tjU@nuoska \
--to=mikko.rapeli@linaro.org \
--cc=f.louveau@lacroix.group \
--cc=yocto@lists.yoctoproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).