Hi Sascha,
On 3/4/26 8:31 AM, Sascha Hauer wrote:
Hi Tom,
On Mon, Mar 02, 2026 at 04:09:37PM -0600, Tom Rini wrote:
There is a flaw in how U-Boot verifies and generates signatures for FIT
images. To prevent mix and match style attacks, it is recommended to
use signed configurations. How this is supposed to work is documented in
doc/usage/fit/signature.rst.
Crucially, the `hashed-nodes` property of the `signature` node contains
which nodes of the FIT device tree were hashed as part of the signature
and should be verified. However, this property itself is not part of the
hash and can therefore be modified by an attacker. Furthermore, the
signature only contains the name of each node and not the path in the
device tree to the node.
This patch reworks the code to address this specific oversight.
As this breaks compatibility between old U-Boot and new FIT images and
the other way round it would be good to introduce a version field to FIT
images. With that at least newer U-Boot versions could print a more
How do we decide when to bump this version?
meaningful error message than just "image verification failed" which
gives no clue what had actually happened.
Here, only signed FIT images with required = conf actually won't work as
far as I understood, the rest will work as usual. So we would need to
keep track of which version(s) of the FIT are supported by which part(s)
of the code, or error out saying it is not supported as soon as it is
parsed but it actually is supported, making incompatibility wider for no
reason?
Not saying it's a bad idea, just that it's not as simple as putting a
version field in there. Also, I'm assuming this would need to be part of
the FIT spec. And I'm wondering if this isn't rather a shortcoming of
U-Boot implementation for FIT signature verification rather than an
issue with the spec, so why should the spec bump the version if an
implementer got it wrong?
Cheers,
Quentin
