All,

Today we discussed Simon's slides [1] about DTB signatures. Simmons points (as I understand them) * U-boot has used signatures in FIT format for years * The technique used for FIT is actually generic to any DTB * Such a signed DTB could still be passed to kernel * even an old one like 4.4 * Suggest we adopt this for signing individual DTBs

Discussion: * General interest in idea, no strong objections * multiple people want to see the worked example to know for sure * Which nodes do we want to sign? * Should we sign in a way that allows the kernel to recheck the signature? * would require we exclude from hashing anything that will get fixed up by u-boot at run time, such as mac addrs and chosen * If u-boot applies any non-trivial DTBO's, the kernel won't be able to check the result, is it worth the effort for the simple case? * If we really want the kernel to verify, we should pass on a set of dtbs: a base and set of overlays, one overlay would be the fixup data. kernel could check each dtb and then verify that fixup data only touches the stuff that it should * Joakim worked with a student to do things very similar to what Simon is talking about. see [2]

Other comments: * verifying 10 rsa signatures on 10 hashes is more expensive than verifying 1 rsa signature of 10 strong hashes. (RSA signatures on the actual data itself would be VERY expensive.) * We should be careful about boot time in all these discussions. * If all the DTB data is internal to u-boot, just use FIT and have one signature for all the various hashes.

* Is it OK to use the "exploded" rsa public key data in all cases? * Is the exploded for faster or just less code? * Can we supply the plan/std pub key AND the exploded version? * implementations that care about speed and code size can use the exploded ver, while things that need to standard key structure can use that. We would need a offline tool to verify both. * UEFI secure boot will have public keys installed. Can we explode the key on install for internal storage?

Actions: * Simon to work up an example of signing just one dtb

We also introduced the topics of DT lifecycle at firmware level: A) Source level lifecycle, keeping things in sync A1) Golden source repo A2: Golden source for platforms that opt-in A3) auto checker but manual fixup A4) remove DT from sub projects and rely on B2 model Pretty sure this is a NOPE! A5) do nothing and trust platforms maintainers to do the right thing (despite evidence that many are not currently). B) runtime life-cycle B1) each component has its own DTB B2) DTB is only present in "first" firmware and is passed along from there B3) mixture of B1 & B2 at different firmware stages

Actions: * Bill to make slides so we can discuss properly on Oct 18.

[1] https://drive.google.com/file/d/1PA5aQ2rISOrdNbqElfIWXaSrCG28Rqx4/view?usp=s... [2] https://github.com/marianomarciello/Device_Tree_Verification/tree/e0b2fc989a...

Thanks, Bill