[U-Boot] RSA in U-Boot

[AKASHI Takahiro <takahiro.akashi@linaro.org>]

Wolfgang,

Thank you for your comments.

On Fri, May 17, 2019 at 10:47:56AM +0200, Wolfgang Denk wrote:
> Dear Akashi Takahiro,
> 
> In message <20190517001206.GX11160@linaro.org> you wrote:
> >
> > > Who: usually the responsible custodians
> >
> > "Custodians" don't always mean sub-system maintainers. Right?
> 
> It's just a different name for the same thing.

Okay.

> > In fact, I have already imported relevant kernel code into U-Boot
> > and it now works perfectly with my experimental UEFI secure boot patch,
> > but see the total size (and numbers) of files imported is quite big.
> > I wonder who is willing to maintain them:
> ...
> >  37 files changed, 6409 insertions(+), 11 deletions(-)
> 
> Well, if you compare for example against  libressl-portable , then
> this git repository has 180 files with more than 20,000 lines.

I think that there are two different approaches in using
external code (library).
1.import necessary source files into U-Boot repository, customize them
  and build them with the rest of U-Boot
2.build it as a static library, either totally outside of U-Boot
  or as a git submodule, and link it, i.e. only needed binary blobs,
  to U-Boot.
  (I don't know any existing libraries like this in U-Boot though.)

We can adopt only (1) for kernel code, but *in general* (2) as well
for a library. That way, we may potentially save/minimize our own
maintenance cost, again *in general.*

Those said, it seems to me that, gnutls, for instance, is not well
optimized for smaller (or purpose-specific) systems. For example,
_wrap_nettle_pk_verify(), public key verification function, supports
not only RSA, but also DSA, ECDSA and so on with no "opt-out" options
while UEFI secure boot only needs and supports RSA.

> We are adding a lot of functionality, and anyone who wants to use
> this will have to pay the price.  But this is what I mentioned
> before:  I think the kernel code has already been tweaked with an
> eye on resource consumption, while standard public libraries have
> not.

I'm not very sure about your last statement above, but as far as
the customisability is concerned some libraries may have an issue
in (2) as I mentioned above.

In this sense, I still want to seek a possibility of using other
smaller libraries, like mbedTLS.
(mbedTLS has another issue, lacking pkcs7 parser.)

> The kernel code may be big, but I would be surprised if there are
> smaller and leaner alternatives with similar quality?
> 
> As for who is willing to maintain it: I have no idea.  Usually it
> turns out to be the original implementoer / who pushed the code
> upstream into U-Boot.

Okay, but for most of examples you mentioned as linux-origin code,
there are no explicit maintainers. Right?

-Takahiro Akashi

> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> miracle:  an  extremely  outstanding  or  unusual  event,  thing,  or
> accomplishment.                                - Webster's Dictionary