On Mon, Mar 28, 2016 at 03:32:40PM -0400, Tom Rini wrote: > I'm interested in getting secure device support going, but it seems > like we should need more than that, ie something to keep the chain of > trust going.
Tom et al., I just saw your reply to Vitaly's email and I'm actually just looking into something along the lines you brought up but I didn't want to hijack that discussion so here's a new thread. As for the chain of trust for ARMv7, my understanding is that when using a combination of SPL and U-Boot there will always be a vendor- specific initial boot (ROM) code that authenticates SPL, and then there will need to be some code inserted into SPL that authenticates U-Boot after it's loaded (for example by using some secure ROM API call and such). So I was looking into if there is already some generic framework for this in U-Boot but didn't see anything obvious. One "easy" way would be to add a simple call to an authentication routine to board_init_r (u-boot/common/spl/spl.c) but let's say we add such a call for TI or other vendor's stuff I suppose this would not scale very well. But what about adding one generic call to a default authentication function declared as __weak for spl_image that doesn't do anything, but can be overwritten in vendor-specific files to provide means of authenticating spl_image. Would this be a good approach? Beyond that I was reviewing some of the awesome work from the Chromium team and I think on ARMv7 after we get MLO to authenticate U-Boot everything beyond that is already looking very solid and thorough (with FIT, DTB/Kernel and initramfs authentication). Thanks and Regards, -- Andreas Dannenberg Texas Instruments Inc _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
