Hi Andreas, On 14 April 2016 at 17:07, Andreas Dannenberg <[email protected]> wrote: > > Hi Simon, thanks for the feedback. Additional comments inlined... > > On Mon, Apr 04, 2016 at 06:04:15PM -0600, Simon Glass wrote: > > Hi Andreas, > > > > On 28 March 2016 at 14:19, Andreas Dannenberg <[email protected]> wrote: > > > 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). > > > > It should be possible to use this from SPL, if you can enable FIT in > > SPL. The current implementation does not support verification, and is > > deliberately cut down. See common/spl/spl_fit.c. > > Oh, I just noticed this file after doing a pull, that's really one step > ahead of the U-Boot versions I've worked with so far. Upon further > digging I found that the general SPL FIT approach is actually something > we are trying to enable for our own customers moving forward. So adding/ > enabling FIT auth in SPL would really help connecting the dots and > closing the current authentication gap not just for us but actually for > all U-Boot users.
Agreed. > > Will look at this more closely and see how much overhead this would > involve since for SPL memory can be of an issue, as using SPL > authenticated FIT will probably mean pulling in the U-Boot crypto stuff > as in such case we would be using U-Boot tooling to generate the signed > FIT image (as opposed to a vendor-specific signing tool generating an > image compatible with a simple SoC ROM API auth call). But looking at > the already memory-optimized U-Boot RSA verification code in > rsa-verify.c and rsa-checksum.c I would hope the impact would not be too > bad. I'd guess maybe 10-20KB total with SHA256, RSA, and the needed code > changes to spl_fit.c. The overhead for U-Boot itself is covered in the 'Verified Boot on Chrome OS and How to do it yourself' talk here: http://elinux.org/ELC_Europe_2013_Presentations Verified boot itself is about 6KB on Thumb 2, on top of the FIT overhead. > > > but you could perhaps > > provide an option to use the full U-Boot implementation instead. > > ...which would mean that the entire U-Boot would need to be loaded > initially as one piece which wouldn't work on some of our SoCs due to > memory constraints (hence the SPL approach). No I don't mean that. I mean use the full U-Boot FIT implementation, i.e. just the same code. It would still run in FIT. Much of the bloat is messages which can be dropped. I did an experiment on this a while ago and already have it on my list to see if I can find any remnants of it. > > -- > Andreas Dannenberg > Texas Instruments Inc > Regards, Simon _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
