[U-Boot] [PATCH] RFC: Secure boot to U-Boot proper from SPL

[Andreas Dannenberg]

Hi Teddy,

On Mon, May 23, 2016 at 01:53:35PM -0400, Teddy Reed wrote:
> 
> > On May 23, 2016, at 1:15 PM, Andreas Dannenberg <dannenberg at ti.com> wrote:
> > 
> >> On Sun, May 08, 2016 at 06:13:50PM -0700, Teddy Reed wrote:
> >>> On Sun, May 1, 2016 at 11:12 AM, Teddy Reed <teddy.reed at gmail.com>
> >>> wrote: I've been using the following patch for my configurations,
> >>> please excuse the top-posting. I think the only difference is
> >>> enabling the uclass mod_exp driver to initialize without needing
> >>> relocation.
> >> 
> >> If no one has any additional notes / requirements for enablement in
> >> SPL I can send my tiny bit of configuration changes as a patch.
> >> 
> >> I've tested the DM flag change for the RSA mod_exp driver class for
> >> both relocated (u-boot) and non-relocated (SPL) builds and found no
> >> issues. It would be awesome to get another set of eyes on the Makefile
> >> feature reorganization as I don't want this to include unneeded code
> >> into SPLs. :)
> > 
> > Hi Teddy,
> > I was just trying to work your patch into my U-Boot tree to experiment
> > with it some when I realized that it requires CONFIG_SPL_DM which is
> > something the platforms I work with don't currently support :(
> > 
> > I'll need to look further and see what I can do about it (using the
> > non-DM rsa_mod_exp_sw routine instead of rsa_mod_exp?) but generally
> > speaking it seems like that non-DM based authentication could be a
> > useful feature for SPL, since one big reason of using an SPL in the
> > first place is to have something that fits into the minimum amount of
> > on-chip RAM possible...
> 
> Definitely! My original goal was verified boot in SPL with a minimum
> set of configuration/code changes. I've been working in the code base
> for a few weeks now and absolutely agree that with a bit more code
> modifications the driver model requirement could removed.
> 
> I do love the concept of representing the EXP implementation as a
> uclass driver, but for highly constrained SPLs it's not the best.
> 
> I think it's a good idea to land the proposed minimum set of
> configuration changes required for verified boot in SPL. Then we can
> iterate together on removing the DM requirement. What do you think?

Yes I think what you have in your RFC is definitely a good starting
point and building this out with additional patches sounds like a
reasonable approach. But as you are preparing your actual initial patch
submission it'd be good to keep in the back of your mind to architect it
such that it can be build upon further... (I realize it's a bit of a
chicken-and-egg problem but I wanted to make that comment anways ha).
But I'm definitely going to further experiment with this and let you
know if there are relevant findings.

Since you seem to be spending quite a bit of energy on the auth stuff I
suppose there is another thing you probably ran into as well which is
related to how the public key gets embedded into the DTB file. When
using CONFIG_SPL_LOAD_FIT to build a FIT blob containing U-Boot and one
or several DTBs I think the mkimage-based process of embedding said
public key [1] doesn't really apply. So for now I "hacked" it by
embedding the public key manually directly in the DTS source files so
that U-Boot can access it but clearly this needs a better solution. I'm
thinking of an approach of where the U-Boot build process would consume
the public key (maybe specified via a CONFIG_xxx) and bake it directly
into DTB file(s) specified by CONFIG_OF_LIST during build before they
get bundled together into a FIT blob but I wonder if you might have
already had some thoughts on this topic.

Thanks and Regards,
Andreas

[1]
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/beaglebone_vboot.txt;h=b4ab28542e50458e1d9eeda0add716426f08b076;hb=HEAD#l208 

> The main reason I suggest multiple patches is because the decoupling
> may also affect non-SPL verified boots. :)
> 
> Take care!  -Teddy