On Wed, Mar 04, 2026 at 05:33:36PM +0100, Quentin Schulz wrote: > 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?
Bump it on incompatible changes. > > > 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? In this case it looked like the spec itself had shortcomings. Anyway, with Simons suggestion of not using the hashed-nodes property things look differently now. My suggestion wasn't meant to imply that you should broadly reject non matching versions, there's no reason to reject any unsigned FIT images when only the signature has changed. A version field would just give you the possibility to detect incompatibilities before running into errors. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
