(1) When one wants to get rid of CONFIG_LEGACY_IMAGE_FORMAT, one also has to wrap any boot script in a FIT rather than a uImage. While it's not directly documented anywhere how to do that, it seems that a minimal .its for achieving it is
/dts-v1/; / { description = "U-Boot script(s)"; images { default = "boot"; boot { description = "Bootscript"; data = /incbin/("boot.txt"); type = "script"; compression = "none"; hash-1 { algo = "sha256"; }; }; }; }; [The UX when one doesn't guess that the description string is mandatory is rather sad, but that's a separate story.] Now, I can get that signed if I include a signature-foo node inside the "boot" node, and also add a dummy empty /configurations node (otherwise mkimage refuses to process it). But that will only work if I have added a "required = image" property with the public key; if I want to use the safer/saner "required = conf", how do I make sure any boot script is properly signed? The code in source.c only cares about the images node and calls fit_image_verify(), and there's no concept of "configuration" and combining multiple images when talking about a simple boot script. (2) Assuming for the moment that I would be happy with just using required=image, am I right in that not only does that mean that the combination of kernel/fdt/initramfs is not verified, merely the individual parts, but more importantly (a mix'n'match attack isn't really very likely), _only_ the data property in each node is part of what gets signed, not the other important properties such as load= and entry=? IOW, suppose I have a FIT image with images { kernel { data = blabla; load = 0x1000000; entry = 0x10000000; signature { ... // correct signature of blabla }; }; }; and I know that the boot process uses $loadaddr = 0x40000000. What is to stop me from modifying that FIT image to read images { kernel { data = blabla; load = 0x1000000; entry = 0x400abcde; signature { ... // correct signature of blabla }; }; }; some-other-node { pwned = /incbin/("pwned"); }; where 0xabcde is chosen to coincide with where the data part of the pwned property lies in the modified FIT? (That pwned property can be put anywhere; I could even just replace the signer-name property inside the signature node with a value of "mkimage\0<padding><my payload>".) In fit_config_process_sig(), there's this elaborate dance with fit_config_get_data()/fdt_find_regions() which, AFAICT, ends up including all the property values (and the FDT_PROP tags and string offsets etc.), and then we call info.crypto->sign() with some appropriate region_count. But in fit_image_process_sig(), we call info.crypto->sign() with nregions==1, and AFAICT, the data being signed is just the value of the "data" property, nothing else. Rasmus