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

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

[Andreas Dannenberg]

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] [RFC] SPL -> U-Boot Chain of Trust

[Simon Glass]

Hi Andreas,

On 28 March 2016 at 14:19, Andreas Dannenberg <dannenberg@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. But you could perhaps
provide an option to use the full U-Boot implementation instead.

>
>
> Thanks and Regards,
>
> --
> Andreas Dannenberg
> Texas Instruments Inc
>

Regards,
Simon

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

[Andreas Dannenberg]

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@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.

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.

> 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).

--
Andreas Dannenberg
Texas Instruments Inc

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

[Simon Glass]

Hi Andreas,

On 14 April 2016 at 17:07, Andreas Dannenberg <dannenberg@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@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.

>
> > 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] [RFC] SPL -> U-Boot Chain of Trust

[Andreas Dannenberg]

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@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@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.

Regards,

--
Andreas Dannenberg
Texas Instruments Inc

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

[Simon Glass]

Hi,

On 27 April 2016 at 09:14, Andreas Dannenberg <dannenberg@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@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@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

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

[Andreas Dannenberg]

On Sun, May 01, 2016 at 01:45:35PM -0600, Simon Glass wrote:
> Hi,
> On 27 April 2016 at 09:14, Andreas Dannenberg <dannenberg@ti.com> wrote:
> > 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/

Hi Simon,
thanks for posting your previous work and also providing some background
and helping to connect the dots... I've seen that there is now a flurry
of activity around SPL and FIT authentication which is great (thanks
Teddy too for posting your work). I agree with your other comment, it
looks like we are much closer to a solution than I thought initially
when starthing this thread.

Regards,
Andreas

--
Andreas Dannenberg
Texas Instruments Inc