Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Fiona Klute via buildroot <buildroot@buildroot.org>
To: Peter Korsgaard <peter@korsgaard.com>
Cc: Fiona Klute via buildroot <buildroot@buildroot.org>
Subject: Re: [Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree
Date: Tue, 1 Sep 2026 14:53:25 +0200	[thread overview]
Message-ID: <3fbbaf51-47dc-4b3a-8a28-7768ae5d42a1@gmx.de> (raw)
In-Reply-To: <875x0p8als.fsf@dell.be.48ers.dk>

Am 01.09.26 um 13:38 schrieb Peter Korsgaard:
>>>>>> "Fiona" == Fiona Klute <fiona.klute@gmx.de> writes:
> 
> Hi,
> 
>   >> Possibly, but should that then be per-fs or global? I wonder if it
>   >> is
>   >> worth the complexity to add this logic versus how fairly simple it is to
>   >> just do it with whatever options you want in a post-image script.
> 
>   > I'd say per-fs. The logic could be shared like the general veritysetup
>   > call, just the option would need to be added for each fs (in
>   > Config.in). I don't think Kconfig has a kind of templating for that?
> 
>   > I agree running veritysetup in a post-image script isn't very
>   > complicated. Where I'm actually trying to do is to have the roothash
>   > of my rootfs before building an initramfs (using
>   > BR2_TARGET_ROOTFS_CPIO_DRACUT), so it can be included (and signed
>   > along with the initramfs, in my case in a FIT image). Of course these
>   > patches don't achieve that, they'd just provide the roothash as a
>   > start.
> 
>   > If you have a better idea how to do that I'm all ears.
> 
> The way I have solved it in the past is to use "late" binding between
> the kernel and rootfs, E.G. only when I build the FIT image by sticking
> the root hash into a u-boot boot script that I generate in my post-image
> script and embed in the FIT.

That's exactly what I'm doing for now, with a config for the script in 
the FIT image running "source $loadaddr#set-roothash" works, but it 
seems kind of convoluted. Especially given Dracut explicitly provides 
the option to embed command line options in the initramfs. :D

>   > script can't do it (rootfs image isn't ready), post-image doesn't have
>   > the fakeroot environment for running Dracut (and other setup [1]).
>   > Maybe we should move building initramfs to a separate stage, after
>   > rootfs (I'd definitely need to order cpio after other fs types), and
>   > add a pre-initramfs script? Is there another non-messy way to use the
>   > fakeroot environment and variables from Buildroot config that I've
>   > missed so far (other than rules in external.mk)?
> 
> Initramfs is indeed annoying because of the circular dependencies. It
> has been quite a while since I last used one. Out of interest, what do
> you need the initramfs for?
Right now for setting up that dm-verity device, in the future probably 
dm-crypt, too. If it was *only* dm-verity I could use dm-mod.create 
(assemble parameters like in the test in post-image) and let the kernel 
handle the rest. Systemd has a bunch of automation for it, which is why 
I've been working on fixing Dracut. ;-)

We don't really need the circular dependency, we just have to order the 
initramfs after the rootfs. Kinda crude, but works (in external.mk):

$(BINARIES_DIR)/rootfs.cpio: $(BINARIES_DIR)/rootfs.squashfs

My general idea so far is to add something similar (but generic) 
conditional on BR2_TARGET_ROOTFS_CPIO_DRACUT=y. We might still need a 
script hook, but maybe a custom Dracut module would be enough (e.g. 
build a veritytab/crypttab and install it in the initramfs). I'm still 
working this out. :-)

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

      reply	other threads:[~2026-09-01 12:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31 12:51 [Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree Fiona Klute via buildroot
2026-08-31 12:51 ` [Buildroot] [PATCH next 2/3] fs/squashfs: add option to build verity tree Fiona Klute via buildroot
2026-08-31 12:51 ` [Buildroot] [PATCH next 3/3] support/testing/tests/fs/test_squashfs.py: add test with dm-verity Fiona Klute via buildroot
2026-08-31 19:16 ` [Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree Peter Korsgaard
2026-08-31 21:10   ` Fiona Klute via buildroot
2026-09-01  6:41     ` Peter Korsgaard
2026-09-01 10:26       ` Fiona Klute via buildroot
2026-09-01 11:38         ` Peter Korsgaard
2026-09-01 12:53           ` Fiona Klute via buildroot [this message]

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=3fbbaf51-47dc-4b3a-8a28-7768ae5d42a1@gmx.de \
    --to=buildroot@buildroot.org \
    --cc=fiona.klute@gmx.de \
    --cc=peter@korsgaard.com \
    /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