[PATCH v2] boot: Add fit_config_get_hash_list() to build signed node list

[Nussel, Ludwig]

On Mon, 2026-03-09 at 11:43 -0600, Simon Glass wrote:
> Hi Ludwig,
> 
> On Mon, 9 Mar 2026 at 11:29, Nussel, Ludwig <ludwig.nussel at siemens.com> wrote:
> > 
> > On Thu, 2026-03-05 at 18:20 -0700, Simon Glass wrote:
> > > From: Simon Glass <simon.glass at canonical.com>
> > > 
> > > The hashed-nodes property in a FIT signature node lists which FDT paths
> > > are included in the signature hash. It is intended as a hint so should
> > > not be used for verification.
> > > 
> > > Add a function to build the node list from scratch by iterating the
> > > configuration's image references. Skip properties known not to be image
> > > references. For each image, collect the path plus all hash and cipher
> > > subnodes.
> > > 
> > > Use the new function in fit_config_check_sig() instead of reading
> > > 'hashed-nodes'.
> > 
> > While growing more grey hair trying to wrap my head around this I found
> > a mean trap. mkimage reads a 'sign-images' property to determine which
> > images to include in the hash regions. Without that property only
> > kernel, fdt and script properties are included at image generation time
> > (see fit_config_get_image_list()).
> > 
> > The new verification code works without such a weird hardcoded list. So
> > as soon as a FIT image has e.g. a ramdisk and it's not listed in 'sign-
> > images' the verification fails.
> 
> Yes I noticed that...I was thinking we could have mkimage report an
> error, but fit_check_sign does do this check.

For me when I tried the patch it wasn't clear why the signature check
failed at first. I assume for anyone not deep in the topic it's just
outright frustrating when there are no helpful error messages. So yes,
I think it makes sense to have mkimage do some checks to make sure
fit_check_sign actually works :-)

> When designing all this I felt it was nice to have a sign-images
> property which explicltly contains the things to sign, since it makes
> you think about what you are doing. But perhaps we could just do
> without it?

Is there a use case for not including images in the signature that are
referenced from a config? IIUC with the current patch it wouldn't work
anyway as signature verification enforces inclusion of all images now.
IMO it would make sense to still read 'hashed-nodes' in the check to
stay compatible (if it's a subset) but complain loudly and declare the
feature deprecated.

cu
Ludwig

-- 
Ludwig Nussel
Siemens AG
www.siemens.com