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,

 > 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