[Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree

[Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree

[Fiona Klute via buildroot]

From: "Fiona Klute (othermo GmbH)" <fiona.klute@gmx.de>

Using dm-verity may be useful for any read-only filesystem read from a
block device, the new hook will build the required hash tree if
enabled by a per-filesystem config option.

Signed-off-by: Fiona Klute (othermo GmbH) <fiona.klute@gmx.de>
---
The change is small, but it's a new feature, so I assume it's for next.
;-)

 fs/common.mk | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/fs/common.mk b/fs/common.mk
index 2f3f8bcc7e..794423476d 100644
--- a/fs/common.mk
+++ b/fs/common.mk
@@ -215,6 +215,15 @@ TARGETS_ROOTFS += rootfs-$(1)
 PACKAGES += $$(filter-out rootfs-%,$$(ROOTFS_$(2)_FINAL_RECURSIVE_DEPENDENCIES))
 endif
 
+ifeq ($$(BR2_TARGET_ROOTFS_$(2)_VERITY),y)
+ROOTFS_$(2)_DEPENDENCIES += host-cryptsetup
+define ROOTFS_$(2)_VERITY_FORMAT
+	@$$(call MESSAGE,"Generating verity hash tree $$(@F).verity")
+	$(HOST_DIR)/sbin/veritysetup format --root-hash-file $$@.verity.root-hash $$@ $$@.verity
+endef
+ROOTFS_$(2)_POST_GEN_HOOKS += ROOTFS_$(2)_VERITY_FORMAT
+endif
+
 # Check for legacy POST_TARGETS rules
 ifneq ($$(ROOTFS_$(2)_POST_TARGETS),)
 $$(error Filesystem $(1) uses post-target rules, which are no longer supported.\
-- 
2.55.0

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

[Buildroot] [PATCH next 2/3] fs/squashfs: add option to build verity tree

[Fiona Klute via buildroot]

From: "Fiona Klute (othermo GmbH)" <fiona.klute@gmx.de>

Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
---
 fs/squashfs/Config.in | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/fs/squashfs/Config.in b/fs/squashfs/Config.in
index cb2f5ec969..c267640401 100644
--- a/fs/squashfs/Config.in
+++ b/fs/squashfs/Config.in
@@ -121,4 +121,16 @@ config BR2_TARGET_ROOTFS_SQUASHFS_COMP_OPTS
 	default "-Xcompression-level 22" if BR2_TARGET_ROOTFS_SQUASHFS4_ZSTD
 	depends on BR2_TARGET_ROOTFS_SQUASHFS_EXTREME_COMP
 
+config BR2_TARGET_ROOTFS_SQUASHFS_VERITY
+	bool "create verity hash data for root filesystem"
+	select BR2_PACKAGE_HOST_CRYPTSETUP
+	help
+	  Create verity hash tree for the root filesystem. This allows
+	  setting up a dm-verity device for the root filesystem, to
+	  ensure data integrity. The root hash must be provided from a
+	  trusted source, or with a kernel-verifiable signature.
+
+	  The verity hash image will be called rootfs.squashfs.verity,
+	  with the root hash in rootfs.squashfs.verity.root-hash.
+
 endif
-- 
2.55.0

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

[Buildroot] [PATCH next 3/3] support/testing/tests/fs/test_squashfs.py: add test with dm-verity

[Fiona Klute via buildroot]

From: "Fiona Klute (othermo GmbH)" <fiona.klute@gmx.de>

This test uses the option added in the previous commits to build a
disk image with squashfs root and matching verity tree, and boots from
it. Building a kernel is necessary to get the required device-mapper
and squashfs support.

The test also serves to demonstrate usage of a verity image, more
complex setup may use an initramfs instead of dm-mod.create.

Signed-off-by: Fiona Klute (othermo GmbH) <fiona.klute@gmx.de>
---
 support/testing/tests/fs/test_squashfs.py     | 85 +++++++++++++++++++
 .../fs/test_squashfs/genimage-verity.cfg      | 14 +++
 .../fs/test_squashfs/linux-verity.fragment    |  8 ++
 3 files changed, 107 insertions(+)
 create mode 100644 support/testing/tests/fs/test_squashfs/genimage-verity.cfg
 create mode 100644 support/testing/tests/fs/test_squashfs/linux-verity.fragment

diff --git a/support/testing/tests/fs/test_squashfs.py b/support/testing/tests/fs/test_squashfs.py
index 0ceb4cab58..eae84fa454 100644
--- a/support/testing/tests/fs/test_squashfs.py
+++ b/support/testing/tests/fs/test_squashfs.py
@@ -1,4 +1,5 @@
 import os
+import re
 
 import infra.basetest
 
@@ -55,3 +56,87 @@ class TestSquashfsMaxBlocksize(TestSquashfs):
         # BR2_TARGET_ROOTFS_TAR is not set
         """
     expected_blocksize_in_bytes = 1024*1024
+
+
+class TestSquashfsVerity(infra.basetest.BRTest):
+    kernel_fragment = \
+        infra.filepath("tests/fs/test_squashfs/linux-verity.fragment")
+    genimage_config = \
+        infra.filepath("tests/fs/test_squashfs/genimage-verity.cfg")
+    config = \
+        f"""
+        BR2_aarch64=y
+        BR2_TOOLCHAIN_EXTERNAL=y
+        BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
+        BR2_LINUX_KERNEL=y
+        BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+        BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.18.48"
+        BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+        BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/aarch64-virt/linux.config"
+        BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="{kernel_fragment}"
+        BR2_TARGET_ROOTFS_SQUASHFS=y
+        BR2_TARGET_ROOTFS_SQUASHFS4_LZO=y
+        BR2_TARGET_ROOTFS_SQUASHFS_VERITY=y
+        BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh"
+        BR2_ROOTFS_POST_SCRIPT_ARGS="-c {genimage_config}"
+        BR2_PACKAGE_CRYPTSETUP=y
+        BR2_PACKAGE_HOST_GENIMAGE=y
+        # BR2_TARGET_ROOTFS_TAR is not set
+        """
+
+    def test_run(self) -> None:
+        img = os.path.join(self.builddir, "images", "rootfs.squashfs")
+        hash_img = f"{img}.verity"
+        root_hash_file = f"{hash_img}.root-hash"
+        verify_cmd = [
+            "host/sbin/veritysetup", "verify",
+            "--root-hash-file", root_hash_file, img, hash_img
+        ]
+        infra.run_cmd_on_host(self.builddir, verify_cmd)
+
+        dump_cmd = ["host/sbin/veritysetup", "dump", hash_img]
+        out = infra.run_cmd_on_host(self.builddir, dump_cmd)
+        params = dict()
+        for line in out.splitlines():
+            m = re.match(r"^(.*):\s+(\S+)", line)
+            if m is None:
+                continue
+            params[m.group(1)] = m.group(2)
+        print(params)
+
+        data_block_size = int(params["Data block size"])
+        data_blocks = int(params["Data blocks"])
+        sector_size = 512  # default
+        data_sectors = data_blocks * data_block_size // sector_size
+        hash_algorithm = params["Hash algorithm"]
+        hash_start_block = 1  # skip header
+        hash_block_size = int(params["Hash block size"])
+        salt = params["Salt"]
+        with open(root_hash_file) as fh:
+            root_hash = fh.read()
+
+        disk_img = os.path.join(self.builddir, "images", "disk.img")
+        kern = os.path.join(self.builddir, "images", "Image")
+        self.emulator.boot(
+            arch="aarch64",
+            kernel=kern,
+            kernel_cmdline=[
+                "console=ttyAMA0",
+                "root=/dev/dm-0",
+                "rootfstype=squashfs",
+                f'dm-mod.create="verity,,,ro,0 {data_sectors} verity 1 '
+                f'/dev/vda1 /dev/vda2 {data_block_size} {hash_block_size} '
+                f'{data_blocks} {hash_start_block} {hash_algorithm} '
+                f'{root_hash} {salt}"',
+            ],
+            options=[
+                "-M", "virt", "-cpu", "cortex-a57", "-m", "256M",
+                "-drive", f"file={disk_img},if=virtio,format=raw",
+            ])
+        self.emulator.login()
+
+        self.assertRunOk("mount | grep '/dev/root on / type squashfs'")
+        out, ret = self.emulator.run("dmsetup info verity", 5)
+        self.assertEqual(ret, 0)
+        state = next(filter(lambda s: s.startswith("State:"), out))
+        self.assertRegex(state, r"^State:\s+ACTIVE \(READ-ONLY\)$")
diff --git a/support/testing/tests/fs/test_squashfs/genimage-verity.cfg b/support/testing/tests/fs/test_squashfs/genimage-verity.cfg
new file mode 100644
index 0000000000..13761dca8e
--- /dev/null
+++ b/support/testing/tests/fs/test_squashfs/genimage-verity.cfg
@@ -0,0 +1,14 @@
+image disk.img {
+	hdimage {
+	}
+
+	partition root {
+		partition-type = 0x83
+		image = "rootfs.squashfs"
+	}
+
+	partition verity {
+		partition-type = 0x83
+		image = "rootfs.squashfs.verity"
+	}
+}
diff --git a/support/testing/tests/fs/test_squashfs/linux-verity.fragment b/support/testing/tests/fs/test_squashfs/linux-verity.fragment
new file mode 100644
index 0000000000..914dc87fbc
--- /dev/null
+++ b/support/testing/tests/fs/test_squashfs/linux-verity.fragment
@@ -0,0 +1,8 @@
+CONFIG_MD=y
+CONFIG_BLK_DEV_DM=y
+CONFIG_DM_VERITY=y
+CONFIG_DM_INIT=y
+CONFIG_CRYPTO_SHA256=y
+CONFIG_MISC_FILESYSTEMS=y
+CONFIG_SQUASHFS=y
+CONFIG_SQUASHFS_LZO=y
-- 
2.55.0

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

Re: [Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree

[Peter Korsgaard]

>>>>> "Fiona" == Fiona Klute via buildroot <buildroot@buildroot.org> writes:

 > From: "Fiona Klute (othermo GmbH)" <fiona.klute@gmx.de>
 > Using dm-verity may be useful for any read-only filesystem read from a
 > block device, the new hook will build the required hash tree if
 > enabled by a per-filesystem config option.

 > Signed-off-by: Fiona Klute (othermo GmbH) <fiona.klute@gmx.de>
 > ---
 > The change is small, but it's a new feature, so I assume it's for next.
 > ;-)

 >  fs/common.mk | 9 +++++++++
 >  1 file changed, 9 insertions(+)

 > diff --git a/fs/common.mk b/fs/common.mk
 > index 2f3f8bcc7e..794423476d 100644
 > --- a/fs/common.mk
 > +++ b/fs/common.mk
 > @@ -215,6 +215,15 @@ TARGETS_ROOTFS += rootfs-$(1)
 >  PACKAGES += $$(filter-out rootfs-%,$$(ROOTFS_$(2)_FINAL_RECURSIVE_DEPENDENCIES))
 >  endif
 
 > +ifeq ($$(BR2_TARGET_ROOTFS_$(2)_VERITY),y)
 > +ROOTFS_$(2)_DEPENDENCIES += host-cryptsetup
 > +define ROOTFS_$(2)_VERITY_FORMAT
 > +	@$$(call MESSAGE,"Generating verity hash tree $$(@F).verity")
 > +	$(HOST_DIR)/sbin/veritysetup format --root-hash-file $$@.verity.root-hash $$@ $$@.verity

What about the user configurable settings such as hash/data block size,
uuid, salt, ...?

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree

[Fiona Klute via buildroot]

Am 31.08.26 um 21:16 schrieb Peter Korsgaard:
>>>>>> "Fiona" == Fiona Klute via buildroot <buildroot@buildroot.org> writes:
> 
>   > From: "Fiona Klute (othermo GmbH)" <fiona.klute@gmx.de>
>   > Using dm-verity may be useful for any read-only filesystem read from a
>   > block device, the new hook will build the required hash tree if
>   > enabled by a per-filesystem config option.
> 
>   > Signed-off-by: Fiona Klute (othermo GmbH) <fiona.klute@gmx.de>
>   > ---
>   > The change is small, but it's a new feature, so I assume it's for next.
>   > ;-)
> 
>   >  fs/common.mk | 9 +++++++++
>   >  1 file changed, 9 insertions(+)
> 
>   > diff --git a/fs/common.mk b/fs/common.mk
>   > index 2f3f8bcc7e..794423476d 100644
>   > --- a/fs/common.mk
>   > +++ b/fs/common.mk
>   > @@ -215,6 +215,15 @@ TARGETS_ROOTFS += rootfs-$(1)
>   >  PACKAGES += $$(filter-out rootfs-%,$$(ROOTFS_$(2)_FINAL_RECURSIVE_DEPENDENCIES))
>   >  endif
>   
>   > +ifeq ($$(BR2_TARGET_ROOTFS_$(2)_VERITY),y)
>   > +ROOTFS_$(2)_DEPENDENCIES += host-cryptsetup
>   > +define ROOTFS_$(2)_VERITY_FORMAT
>   > +	@$$(call MESSAGE,"Generating verity hash tree $$(@F).verity")
>   > +	$(HOST_DIR)/sbin/veritysetup format --root-hash-file $$@.verity.root-hash $$@ $$@.verity
> 
> What about the user configurable settings such as hash/data block size,
> uuid, salt, ...?
How about an _EXTRA_ARGS option? I think adding options for all possible 
parameters would be a lot of code for little gain.

For hash algorithm a specific option might sense if we could use that to 
ensure the matching hash is enabled in the kernel. But that'd require 
adding LINUX_CONFIG_FIXUPS infrastructure for fs/, not sure if worth it? 
Though enabling filesystems selected for rootfs in the kernel could be 
useful, too (I've been there, changed rootfs and forgot to enable it in 
the kernel – not often, but it happens).

The one reason I can imagine wanting to set uuid/salt is if someone 
wants a byte-identical verity partition. fs/erofs sets all-zero UUID, 
which we could do for verity too, but I'm not sure what the security 
implications of a fixed (or pseudorandom?) salt would be.

Best regards,
Fiona

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

Re: [Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree

[Peter Korsgaard]

>>>>> "Fiona" == Fiona Klute <fiona.klute@gmx.de> writes:

Hi,

 > How about an _EXTRA_ARGS option? I think adding options for all
 > possible parameters would be a lot of code for little gain.

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.


 > For hash algorithm a specific option might sense if we could use that
 > to ensure the matching hash is enabled in the kernel. But that'd
 > require adding LINUX_CONFIG_FIXUPS infrastructure for fs/, not sure if
 > worth it? Though enabling filesystems selected for rootfs in the
 > kernel could be useful, too (I've been there, changed rootfs and
 > forgot to enable it in the kernel – not often, but it happens).

I would be OK with that. These fixups are a bit icky though as we do not
know what kernel version will be used and the dependencies may change
over time - So maintenance and testing is not so trivial.


 > The one reason I can imagine wanting to set uuid/salt is if someone
 > wants a byte-identical verity partition. fs/erofs sets all-zero UUID,
 > which we could do for verity too, but I'm not sure what the security
 > implications of a fixed (or pseudorandom?) salt would be.

Yes, it is also only in the context of reproducible builds that I have
ever used a fixed uuid/salt.

Security wise, as this is about hashing rather than encryption I *THINK*
it is fine as long as the hashing algorithm is strong enough (E.G. you
would need find same-size collisions).

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree

[Fiona Klute via buildroot]

Hi Peter!

Am 01.09.26 um 08:41 schrieb Peter Korsgaard:
>>>>>> "Fiona" == Fiona Klute <fiona.klute@gmx.de> writes:
>   > How about an _EXTRA_ARGS option? I think adding options for all
>   > possible parameters would be a lot of code for little gain.
> 
> 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. Post-build 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)?

>   > For hash algorithm a specific option might sense if we could use that
>   > to ensure the matching hash is enabled in the kernel. But that'd
>   > require adding LINUX_CONFIG_FIXUPS infrastructure for fs/, not sure if
>   > worth it? Though enabling filesystems selected for rootfs in the
>   > kernel could be useful, too (I've been there, changed rootfs and
>   > forgot to enable it in the kernel – not often, but it happens).
> 
> I would be OK with that. These fixups are a bit icky though as we do not
> know what kernel version will be used and the dependencies may change
> over time - So maintenance and testing is not so trivial.

Yeah, and for something that you'll usually set up once and update only 
rarely, which is why I'm not sure it's worth it. And many filesystems 
have extra kernel options we can't guess anyway.

>   > The one reason I can imagine wanting to set uuid/salt is if someone
>   > wants a byte-identical verity partition. fs/erofs sets all-zero UUID,
>   > which we could do for verity too, but I'm not sure what the security
>   > implications of a fixed (or pseudorandom?) salt would be.
> 
> Yes, it is also only in the context of reproducible builds that I have
> ever used a fixed uuid/salt.
> 
> Security wise, as this is about hashing rather than encryption I *THINK*
> it is fine as long as the hashing algorithm is strong enough (E.G. you
> would need find same-size collisions).

I don't *see* any huge problem either, but making a fixed salt the 
default seems risky. If someone sets that via an _EXTRA_ARGS option 
that's their responsibility. ;-)

Best regards,
Fiona


[1] I have a bunch of fixes lined up to add environment variables Dracut 
needs for cross-building, but some will need the next Dracut release 
(unless we want to add a lot of patches), and the others aren't very 
useful on their own. Biggest still-open chunk: 
https://github.com/dracut-ng/dracut/pull/2588

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

Re: [Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree

[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.

U-Boot can afaik source a boot script from a FIT image nowadays, but I
wanted it more integrated into the bootm flow, so I simply added the
bootscript as a type = "script" data file and referred to it from the
configuration with:

 kernel = "kernel-1";
 fdt = ..
 loadables = "script-1";

And then some trivial logic in my board code to handle such loadable:

/* support "script" loadables in FIT images */
static void board_script_handler(ulong addr, size_t size)
{
        run_command_list((char *)addr, size, 0);
}

U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_SCRIPT, board_script_handler);


 > 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?


 >> I would be OK with that. These fixups are a bit icky though as we do
 >> not
 >> know what kernel version will be used and the dependencies may change
 >> over time - So maintenance and testing is not so trivial.

 > Yeah, and for something that you'll usually set up once and update
 > only rarely, which is why I'm not sure it's worth it. And many
 > filesystems have extra kernel options we can't guess anyway.

Exactly!


 >> > The one reason I can imagine wanting to set uuid/salt is if someone
 >> > wants a byte-identical verity partition. fs/erofs sets all-zero UUID,
 >> > which we could do for verity too, but I'm not sure what the security
 >> > implications of a fixed (or pseudorandom?) salt would be.
 >> Yes, it is also only in the context of reproducible builds that I
 >> have
 >> ever used a fixed uuid/salt.
 >> Security wise, as this is about hashing rather than encryption I
 >> *THINK*
 >> it is fine as long as the hashing algorithm is strong enough (E.G. you
 >> would need find same-size collisions).

 > I don't *see* any huge problem either, but making a fixed salt the
 > default seems risky. If someone sets that via an _EXTRA_ARGS option
 > that's their responsibility. ;-)

;)

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree

[Fiona Klute via buildroot]

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