* Verity hash in kernel bootscript
@ 2024-05-02 9:28 f.louveau
2024-05-02 10:34 ` [yocto] " Mikko Rapeli
0 siblings, 1 reply; 4+ messages in thread
From: f.louveau @ 2024-05-02 9:28 UTC (permalink / raw
To: yocto
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1338 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [yocto] Verity hash in kernel bootscript
2024-05-02 9:28 Verity hash in kernel bootscript f.louveau
@ 2024-05-02 10:34 ` Mikko Rapeli
2024-05-02 12:11 ` f.louveau
0 siblings, 1 reply; 4+ messages in thread
From: Mikko Rapeli @ 2024-05-02 10:34 UTC (permalink / raw
To: yocto, f.louveau
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-05-06 8:08 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-02 9:28 Verity hash in kernel bootscript f.louveau
2024-05-02 10:34 ` [yocto] " Mikko Rapeli
2024-05-02 12:11 ` f.louveau
2024-05-06 8:07 ` f.louveau
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).