On Tue, Oct 13, 2026 at 10:16:08PM +0200, anon87111 wrote:
> fit_image_verify_required_sigs() walks the keys in the control FDT, picks
> out those whose "required" property is "image", and passes each key's node
> offset to fit_image_verify_sig(). That function takes the offset as
> key_offset and never uses it: it calls fit_image_check_sig() with
> required_keynode hardcoded to -1, which both boot/image-fit-sig.c and
> include/image.h document as "-1 then any signature will do".
>
> With required_keynode == -1, rsa_verify() skips the "See if we must use a
> particular key" branch, tries the key named by the FIT's own key-name-hint
> property, and then falls through to "try each of the keys in turn". So
> every required-key iteration is satisfied by any signature in the FIT that
> verifies under any key in the control FDT, not by the key the iteration is
> supposed to be checking.
>
> Where two or more keys are marked required = "image", a single signature
> from any one of them therefore satisfies the whole policy. Possession of
> one required image key is enough to boot an arbitrary image, and the other
> required keys contribute nothing. doc/usage/fit/signature.rst says of
> "required": "this indicates that the key must be verified for the image /
> configuration to be considered valid."
>
> The configuration path in the same file does this correctly:
> fit_config_verify_key() passes key_offset straight through to
> fit_config_check_sig(), and fit_config_verify_required_keys() additionally
> honours the required-mode "any"/"all" policy, defaulting to "all". The two
> functions were written as a pair; only one binds the key.
>
> Reproduced on sandbox at b871f722 with two keys marked required = "image"
> and a FIT carrying only a dev signature:
>
> keys marked required = "image": 2 (key-dev, key-prod)
> FIT signatures present : sha256,rsa2048:dev only
>
> Verifying Hash Integrity ... sha256,rsa2048:dev+ sha256,rsa2048:dev+ OK
> ## Transferring control to Linux (at address 000001cc)...
> sandbox: continuing, as we cannot run Linux
>
> The doubled "dev+ dev+" is the defect: one dev signature satisfied both
> iterations, including the one for key-prod. The same scenario against the
> configuration gate, same keys and same default policy, correctly refuses:
>
> Verifying Hash Integrity ... sha256,rsa2048:dev+ sha256,rsa2048:dev-
> error!
> Verification failed for 'conf-1' config node
> Failed to verify required signature 'key-prod'
>
> With this patch the image gate refuses the same way, and the configuration
> gate is unchanged.
>
> The hardcoded -1 dates to 56518e7104 ("image: Support signing of images",
> v2013.07), where fit_image_verify_sig() already took sig_offset without
> using it. 99f844ba3a ("tools: Pass the key blob around") added key_blob
> and left the -1 in place, in the same commit that kept key_offset wired up
> on the configuration side. It has survived because nothing exercises it:
> there is no required = "image" anywhere in the tree, and
> test_required_key() builds only sign-configs-* fixtures, so the image gate
> has never been run with more than one required key.
Should this commit carry a fixes tag?
> This is separate from, and complementary to, the fail-open gate reported
> on the list on 2026-09-07 and patched in "[PATCH 0/2] image-fit-sig: close
> the image-signature fail-open gate". That one is about a control FDT with
> no /signature node at all; this one is about two keys being marked
> required and one signature satisfying both. That fix leaves this behaviour
> in place and this fix leaves that one in place, so both are needed. It is
> also separate from "[PATCH v10 0/7] Improve FIT signature handling" [1],
> which covers the configuration gate.
I only give it a brief glance, (at least) this paragraph sounds like
background, too detailed and less relevant to put in the commit message.
You might want to move it under the "---" line.
Regards,
Yao Zi
