[U-Boot] [RFC] SPL -> U-Boot Chain of Trust

[Simon Glass]

Hi,

On 27 April 2016 at 09:14, Andreas Dannenberg <dannenberg at ti.com> wrote:
> On Wed, Apr 27, 2016 at 08:34:50AM -0600, Simon Glass wrote:
>> Hi Andreas,
>>
>> On 14 April 2016 at 17:07, Andreas Dannenberg <dannenberg at ti.com> 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 <dannenberg at ti.com> 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.
>
> Hi Simon,
> I had actually seen/reviewed this presentation earlier and thought it was
> very helpful to get started so thanks for pointing this out again.
>
>> > > 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.
>
> Ok understood, that would seem to make it easier/cleaner from an
> implementation POV. Still, I've concerns specifically with one of our
> SoCs of which its high-security device variant apparently only has
> something to the order of 45KB for SPL use, which folks had to make a
> lot of effort to strip down/squeeze in a custom SPL, even going as far
> as trimming down strings (and that's using a proprietary authentication
> scheme for U-Boot that almost doesn't take any space at all). I need to
> find some time to dig deeper and play with the bits and bytes but my
> current thinking is to try to pursue the SPL-based FIT approach you
> suggested for the general use case, but have one exception for that
> particular one SoC using a vendor-specific authentication approach since
> there might not be another way due to the memory constraints.
>
>> 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.
>
> Yeah please let me/us know if there is something you have that could be
> recycled.

I just sent a patch referring to this. I didn't find anything but in
fact it is pretty easy now as a lot of the work is done. Or at least
he hard part is now the logic of which image to load, not the code
building.

http://patchwork.ozlabs.org/patch/617228/

Also see Teddy's version:

http://patchwork.ozlabs.org/patch/617229/

Regards,
Simon