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=sharing
[2]
https://github.com/marianomarciello/Device_Tree_Verification/tree/e0b2fc989acb00aa73b62d03409a210631deae43
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
