Tom asked me to base my image-gate series on v9, so I tried it. Two
findings, both about v9 rather than my patches.

v9 does not apply to current main (a44f46af0a). 1/8 is already
upstream and 2/8-5/8 apply with -3, but 6/8 conflicts in
fit_all_image_verify():

  <<<<<<< HEAD
                if (!fit_image_verify(fit, noffset))
                        return 0;
                printf("\n");
  =======
                        if (!fit_image_verify(fit, noffset))
                                return 0;
                        printf("OK\n");
                }

Cause is 2c9b117aa4 ("boot/fit: use fdt_for_each_subnode() in
image-fit.c", 2026-05-08), which dropped a nesting level. v9 was
written against the older form. 7/8 and 8/8 are untested behind it.

So: Tom, which base do you want for mine? Rebasing onto v9's own base
commit moves me back onto the July tag, which is not submittable
against main. I would rather wait for a v10 on current main than post
a resolution of someone else's series.

One other thing, Ludwig. v9's "restore debug message instead of error"
walks the missing /signature report on the config gate back to
debug(). My image-gate patch moves the same condition the other way,
to log_warning() at default loglevel. No code conflict - different
functions - but landed together the tree has two adjacent gates
reading the same node, one silent and one not. With
FIT_REQUIRE_CONFIG_SIGS=y yours returns -EPERM having printed nothing.
Happy to align with whatever you settled on; I just do not want the
two to read as an accident.

Eva Crystal (0xiviel)
XSource Security
https://xsourcesec.com

On Wed, Sep 16, 2026 at 7:50 AM Tom Rini <[email protected]> wrote:
>
> On Tue, Sep 15, 2026 at 07:18:15PM +0200, Ludwig Nussel wrote:
> > On 9/15/26 17:41, Tom Rini wrote:
> > > On Tue, Sep 15, 2026 at 08:45:23PM +1200, Eva Crystal wrote:
> > > > Thanks Ludwig - I hadn't referenced your series in my cover letter,
> > > > and I should have.
> > > >
> > > > v8 4/8 does close the configuration side: 
> > > > fit_config_verify_required_keys()
> > > > gains FIT_REQUIRE_CONFIG_SIGS and fails closed when no keys with
> > > > required='conf' are present.
> > > >
> > > > The case I reported is the other gate. fit_image_verify_required_sigs()
> > > > looks up the /signature node in the control DTB and, when it is missing,
> > > > sets *no_sigsp = 1 and returns 0 with only a debug() message. Every 
> > > > caller
> > > > then treats the image as not requiring signatures, so nothing downstream
> > > > can fail. As far as I can see from your v8 hunks that path is unchanged.
> > > >
> > > > Two things follow:
> > > >
> > > > - I picked FIT_REQUIRE_CONFIG_SIGS for my Kconfig symbol, which collides
> > > >    with yours. I'll rename mine to FIT_REQUIRE_IMAGE_SIGS (plus the SPL
> > > >    variant), default off, since the two gates have different blast 
> > > > radius.
> > > >
> > > > - Jonas raised on 4/8 that Rockchip uses FIT_SIGNATURE for image 
> > > > integrity
> > > >    only, not signed configurations. An image-side required-signature 
> > > > gate
> > > >    hits that setup directly, which is the other reason to keep it a 
> > > > separate
> > > >    symbol that is off by default.
> > > >
> > > > I'll rebase on top of your series and resend once v8 lands, rather than
> > > > adding a patch to a series that already carries review tags.
> > > >
> > > > Tom, shout if you'd rather see it folded in instead.
> > >
> > > Since Ludwig is already working in this area, I'd like his thoughts on
> > > the issue / solution, and if it would make more sense to fold this in to
> > > his series or not. Thanks.
> >
> > I didn't touch the image path at all indeed. So perfect if Eva takes care of
> > that. My series already contains too many things and had too many
> > iterations. I fear that expanding the scope would delay acceptance further.
>
> OK, thanks. Eva, go ahead and just make yours based on top of Ludwig's
> v9 (the changes for v10 shouldn't matter).
>
> --
> Tom

Reply via email to