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

[Peter Korsgaard <peter@korsgaard.com>]

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