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

[Fiona Klute]

Hi Peter!

Am 01.09.26 um 08:41 schrieb Peter Korsgaard:
>>>>>> "Fiona" == Fiona Klute <fiona.klute at 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