[U-Boot] RSA in U-Boot

[Tom Rini]

On Wed, Jun 05, 2019 at 02:27:32PM +0900, AKASHI Takahiro wrote:
> Tom, Wolfgang,
> 
> On Wed, May 22, 2019 at 02:48:42PM +0900, AKASHI Takahiro wrote:
> > 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 at 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?
> 
> Do you have any further comments regarding maintainability?
> (The *quality*, or trustworthiness, of the original code is
> an orthogonal issue.)

No, I see it as a rather settled point that we leverage the linux kernel
code as much as possible, when possible, as a rule of thumb even for the
project.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190605/dd00c7e4/attachment.sig>