[U-Boot] RSA in U-Boot

[U-Boot] RSA in U-Boot

[AKASHI, Takahiro]

Hi,

I'd like to discuss this topic in public.
I will appreciate your comments here.
# FYI, I now started to experimentally port linux's pkcs7/x509
# parser.

Thanks,
-Takahiro Akashi

----- Forwarded message from Simon Glass <sjg@chromium.org> -----

Date: Thu, 7 Mar 2019 19:56:10 -0700
From: Simon Glass <sjg@chromium.org>
To: "AKASHI, Takahiro" <takahiro.akashi@linaro.org>
Subject: Re: RSA in U-Boot

Hi Takahiro,

On Thu, 7 Mar 2019 at 17:27, AKASHI, Takahiro
<takahiro.akashi@linaro.org> wrote:
>
> Hi Simon,
>
> Before I start discussions publicly, I'd like to hear
> your opinion first.

I do think it is better to discuss this in public since there will be
other opinions.

>
> I'm now working on implementing "secure boot"
> for UEFI U-Boot.
>
> As you might know, there are a couple of features
> required to achieve "secure boot":
> (I won't discuss about secure storage here though.)
> - x509 certificate decoder
> - pkcs7 decoder (for PE file's signature)
> - RSA verification
> - (hash digest, sha256)
>
> The original code, which was written by some other guy,
> Patrick, uses BearSSL for x509 and RSA and
> I'm now wondering what is the best solution.
> Obviously, I can think of several options here:
> 1. use BearSSL
>   1.a just import minimum set of files akin lib/libfdt
>   1.b link whole BearSSL as a library, merging the code
>         as git submodule
> 2. use openssl
> 3. import linux kernel code, particularly x509 & pkcs7 parser
> 4. write our own code
>
> I suppose that you weighed similar choices when you implemented
> "FIT image signing".
> Can you share your opinion with me?

I think if you can do 3 then it keeps U-Boot self-contained and
perhaps provides for simple code. That said, if the amount of code is
large and has an upstream there is clear precident for 1a, as you say.

I am not sure about 4. If it is a relatively small amount of code,
then maybe, but surely it makes sense to use the linux code where
possible. That is what I did with the U-Boot livetree code.

1b sounds painful to me.

>
> Regarding your lib/rsa code, you intentionally avoided to
> add formula of inverse-mod and power-mod of R. Do you still
> believe that the assumption is appropriate?
> (BearSSL implements its own montgomery.

If you look at a talk I gave on this, you can see that one of the
goals was to implement it efficiently, with minimal extra code at
run-time, and minimal memory usage. So unpacking complex key
structures did not seem like a good idea. From memory you can do
verified boot in about 7KB of extra code in U-Boot and it runs in a
small number of milliseconds.

UEFI is obviously pretty big, so perhaps efficiency concerns are less
important. More important probably is wide compatibility, supporting
all possible options, etc.

I hope this is helpful.

Regards,
Simon

----- End forwarded message -----

[U-Boot] RSA in U-Boot

[AKASHI, Takahiro]

Update and reminder.

On Mon, Mar 18, 2019 at 11:17:14AM +0900, AKASHI, Takahiro wrote:
> Hi,
> 
> I'd like to discuss this topic in public.
> I will appreciate your comments here.
> # FYI, I now started to experimentally port linux's pkcs7/x509
> # parser.

I've done porting linux's pkcs7/x509 parsers and they work well
with my UEFI secure boot patch, but I'm still looking for other options
as well.

* openssl
  Most of existing components linked to UEFI secure boot, including
  EDK2, shim and grub, reply on this library. Why not for U-Boot?
  The size of U-Boot UEFI code in U-Boot is already quite big, and
  so the size of openssl won't be a big issue.
* mbedTLS
  which is maintained by ARM and used with Zephyr, I guess it should
  have small footprint. But it currently lacks pkcs7 parser.

Any thoughts?

Thanks,
-Takahiro Akashi


> Thanks,
> -Takahiro Akashi
> 
> ----- Forwarded message from Simon Glass <sjg@chromium.org> -----
> 
> Date: Thu, 7 Mar 2019 19:56:10 -0700
> From: Simon Glass <sjg@chromium.org>
> To: "AKASHI, Takahiro" <takahiro.akashi@linaro.org>
> Subject: Re: RSA in U-Boot
> 
> Hi Takahiro,
> 
> On Thu, 7 Mar 2019 at 17:27, AKASHI, Takahiro
> <takahiro.akashi@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > Before I start discussions publicly, I'd like to hear
> > your opinion first.
> 
> I do think it is better to discuss this in public since there will be
> other opinions.
> 
> >
> > I'm now working on implementing "secure boot"
> > for UEFI U-Boot.
> >
> > As you might know, there are a couple of features
> > required to achieve "secure boot":
> > (I won't discuss about secure storage here though.)
> > - x509 certificate decoder
> > - pkcs7 decoder (for PE file's signature)
> > - RSA verification
> > - (hash digest, sha256)
> >
> > The original code, which was written by some other guy,
> > Patrick, uses BearSSL for x509 and RSA and
> > I'm now wondering what is the best solution.
> > Obviously, I can think of several options here:
> > 1. use BearSSL
> >   1.a just import minimum set of files akin lib/libfdt
> >   1.b link whole BearSSL as a library, merging the code
> >         as git submodule
> > 2. use openssl
> > 3. import linux kernel code, particularly x509 & pkcs7 parser
> > 4. write our own code
> >
> > I suppose that you weighed similar choices when you implemented
> > "FIT image signing".
> > Can you share your opinion with me?
> 
> I think if you can do 3 then it keeps U-Boot self-contained and
> perhaps provides for simple code. That said, if the amount of code is
> large and has an upstream there is clear precident for 1a, as you say.
> 
> I am not sure about 4. If it is a relatively small amount of code,
> then maybe, but surely it makes sense to use the linux code where
> possible. That is what I did with the U-Boot livetree code.
> 
> 1b sounds painful to me.
> 
> >
> > Regarding your lib/rsa code, you intentionally avoided to
> > add formula of inverse-mod and power-mod of R. Do you still
> > believe that the assumption is appropriate?
> > (BearSSL implements its own montgomery.
> 
> If you look at a talk I gave on this, you can see that one of the
> goals was to implement it efficiently, with minimal extra code at
> run-time, and minimal memory usage. So unpacking complex key
> structures did not seem like a good idea. From memory you can do
> verified boot in about 7KB of extra code in U-Boot and it runs in a
> small number of milliseconds.
> 
> UEFI is obviously pretty big, so perhaps efficiency concerns are less
> important. More important probably is wide compatibility, supporting
> all possible options, etc.
> 
> I hope this is helpful.
> 
> Regards,
> Simon
> 
> ----- End forwarded message -----

[U-Boot] RSA in U-Boot

[Alexander Graf]

On 25.04.19 04:12, AKASHI, Takahiro wrote:
> Update and reminder.
>
> On Mon, Mar 18, 2019 at 11:17:14AM +0900, AKASHI, Takahiro wrote:
>> Hi,
>>
>> I'd like to discuss this topic in public.
>> I will appreciate your comments here.
>> # FYI, I now started to experimentally port linux's pkcs7/x509
>> # parser.
> I've done porting linux's pkcs7/x509 parsers and they work well
> with my UEFI secure boot patch, but I'm still looking for other options
> as well.
>
> * openssl
>   Most of existing components linked to UEFI secure boot, including
>   EDK2, shim and grub, reply on this library. Why not for U-Boot?
>   The size of U-Boot UEFI code in U-Boot is already quite big, and
>   so the size of openssl won't be a big issue.
> * mbedTLS
>   which is maintained by ARM and used with Zephyr, I guess it should
>   have small footprint. But it currently lacks pkcs7 parser.
>
> Any thoughts?


Paolo, Laszlo, Ard, if you could write a new secure boot implementation
today, which of the options above would you pick and why so? :)


Thanks,

Alex


>
> Thanks,
> -Takahiro Akashi
>
>
>> Thanks,
>> -Takahiro Akashi
>>
>> ----- Forwarded message from Simon Glass <sjg@chromium.org> -----
>>
>> Date: Thu, 7 Mar 2019 19:56:10 -0700
>> From: Simon Glass <sjg@chromium.org>
>> To: "AKASHI, Takahiro" <takahiro.akashi@linaro.org>
>> Subject: Re: RSA in U-Boot
>>
>> Hi Takahiro,
>>
>> On Thu, 7 Mar 2019 at 17:27, AKASHI, Takahiro
>> <takahiro.akashi@linaro.org> wrote:
>>> Hi Simon,
>>>
>>> Before I start discussions publicly, I'd like to hear
>>> your opinion first.
>> I do think it is better to discuss this in public since there will be
>> other opinions.
>>
>>> I'm now working on implementing "secure boot"
>>> for UEFI U-Boot.
>>>
>>> As you might know, there are a couple of features
>>> required to achieve "secure boot":
>>> (I won't discuss about secure storage here though.)
>>> - x509 certificate decoder
>>> - pkcs7 decoder (for PE file's signature)
>>> - RSA verification
>>> - (hash digest, sha256)
>>>
>>> The original code, which was written by some other guy,
>>> Patrick, uses BearSSL for x509 and RSA and
>>> I'm now wondering what is the best solution.
>>> Obviously, I can think of several options here:
>>> 1. use BearSSL
>>>   1.a just import minimum set of files akin lib/libfdt
>>>   1.b link whole BearSSL as a library, merging the code
>>>         as git submodule
>>> 2. use openssl
>>> 3. import linux kernel code, particularly x509 & pkcs7 parser
>>> 4. write our own code
>>>
>>> I suppose that you weighed similar choices when you implemented
>>> "FIT image signing".
>>> Can you share your opinion with me?
>> I think if you can do 3 then it keeps U-Boot self-contained and
>> perhaps provides for simple code. That said, if the amount of code is
>> large and has an upstream there is clear precident for 1a, as you say.
>>
>> I am not sure about 4. If it is a relatively small amount of code,
>> then maybe, but surely it makes sense to use the linux code where
>> possible. That is what I did with the U-Boot livetree code.
>>
>> 1b sounds painful to me.
>>
>>> Regarding your lib/rsa code, you intentionally avoided to
>>> add formula of inverse-mod and power-mod of R. Do you still
>>> believe that the assumption is appropriate?
>>> (BearSSL implements its own montgomery.
>> If you look at a talk I gave on this, you can see that one of the
>> goals was to implement it efficiently, with minimal extra code at
>> run-time, and minimal memory usage. So unpacking complex key
>> structures did not seem like a good idea. From memory you can do
>> verified boot in about 7KB of extra code in U-Boot and it runs in a
>> small number of milliseconds.
>>
>> UEFI is obviously pretty big, so perhaps efficiency concerns are less
>> important. More important probably is wide compatibility, supporting
>> all possible options, etc.
>>
>> I hope this is helpful.
>>
>> Regards,
>> Simon
>>
>> ----- End forwarded message -----

[U-Boot] RSA in U-Boot

[Laszlo Ersek]

On 04/26/19 11:05, Alexander Graf wrote:
> 
> On 25.04.19 04:12, AKASHI, Takahiro wrote:
>> Update and reminder.
>>
>> On Mon, Mar 18, 2019 at 11:17:14AM +0900, AKASHI, Takahiro wrote:
>>> Hi,
>>>
>>> I'd like to discuss this topic in public.
>>> I will appreciate your comments here.
>>> # FYI, I now started to experimentally port linux's pkcs7/x509
>>> # parser.
>> I've done porting linux's pkcs7/x509 parsers and they work well
>> with my UEFI secure boot patch, but I'm still looking for other options
>> as well.
>>
>> * openssl
>>   Most of existing components linked to UEFI secure boot, including
>>   EDK2, shim and grub, reply on this library. Why not for U-Boot?
>>   The size of U-Boot UEFI code in U-Boot is already quite big, and
>>   so the size of openssl won't be a big issue.
>> * mbedTLS
>>   which is maintained by ARM and used with Zephyr, I guess it should
>>   have small footprint. But it currently lacks pkcs7 parser.
>>
>> Any thoughts?
> 
> 
> Paolo, Laszlo, Ard, if you could write a new secure boot implementation
> today, which of the options above would you pick and why so? :)

Difficult question. Ideally you'd want a library where three aspects met:

- widely used (so that there is a diverse community that's interested in
vulnerabilities, and fixing them too)

- easy to cross-compile for your free-standing environment (optimally
the upstream project would support being cross-compiled and packaged
stand-alone, for that free-standing environment)

- cares about API stability

OpenSSL is very widely used...
...and that's where we can stop in the list :)

Rolling your own covers #2 and #3, but lack of #1 makes security people
very nervous. (Rightfully so, I believe.)

Ultimately I think security expertise is the scarcest resource, so I'd
go with #1 -- I'd pick whichever project comes with the largest user
base and most scrutiny.

Thanks
Laszlo

>>> ----- Forwarded message from Simon Glass <sjg@chromium.org> -----
>>>
>>> Date: Thu, 7 Mar 2019 19:56:10 -0700
>>> From: Simon Glass <sjg@chromium.org>
>>> To: "AKASHI, Takahiro" <takahiro.akashi@linaro.org>
>>> Subject: Re: RSA in U-Boot
>>>
>>> Hi Takahiro,
>>>
>>> On Thu, 7 Mar 2019 at 17:27, AKASHI, Takahiro
>>> <takahiro.akashi@linaro.org> wrote:
>>>> Hi Simon,
>>>>
>>>> Before I start discussions publicly, I'd like to hear
>>>> your opinion first.
>>> I do think it is better to discuss this in public since there will be
>>> other opinions.
>>>
>>>> I'm now working on implementing "secure boot"
>>>> for UEFI U-Boot.
>>>>
>>>> As you might know, there are a couple of features
>>>> required to achieve "secure boot":
>>>> (I won't discuss about secure storage here though.)
>>>> - x509 certificate decoder
>>>> - pkcs7 decoder (for PE file's signature)
>>>> - RSA verification
>>>> - (hash digest, sha256)
>>>>
>>>> The original code, which was written by some other guy,
>>>> Patrick, uses BearSSL for x509 and RSA and
>>>> I'm now wondering what is the best solution.
>>>> Obviously, I can think of several options here:
>>>> 1. use BearSSL
>>>>   1.a just import minimum set of files akin lib/libfdt
>>>>   1.b link whole BearSSL as a library, merging the code
>>>>         as git submodule
>>>> 2. use openssl
>>>> 3. import linux kernel code, particularly x509 & pkcs7 parser
>>>> 4. write our own code
>>>>
>>>> I suppose that you weighed similar choices when you implemented
>>>> "FIT image signing".
>>>> Can you share your opinion with me?
>>> I think if you can do 3 then it keeps U-Boot self-contained and
>>> perhaps provides for simple code. That said, if the amount of code is
>>> large and has an upstream there is clear precident for 1a, as you say.
>>>
>>> I am not sure about 4. If it is a relatively small amount of code,
>>> then maybe, but surely it makes sense to use the linux code where
>>> possible. That is what I did with the U-Boot livetree code.
>>>
>>> 1b sounds painful to me.
>>>
>>>> Regarding your lib/rsa code, you intentionally avoided to
>>>> add formula of inverse-mod and power-mod of R. Do you still
>>>> believe that the assumption is appropriate?
>>>> (BearSSL implements its own montgomery.
>>> If you look at a talk I gave on this, you can see that one of the
>>> goals was to implement it efficiently, with minimal extra code at
>>> run-time, and minimal memory usage. So unpacking complex key
>>> structures did not seem like a good idea. From memory you can do
>>> verified boot in about 7KB of extra code in U-Boot and it runs in a
>>> small number of milliseconds.
>>>
>>> UEFI is obviously pretty big, so perhaps efficiency concerns are less
>>> important. More important probably is wide compatibility, supporting
>>> all possible options, etc.
>>>
>>> I hope this is helpful.
>>>
>>> Regards,
>>> Simon
>>>
>>> ----- End forwarded message -----

[U-Boot] RSA in U-Boot

[Paolo Bonzini]

> >> I've done porting linux's pkcs7/x509 parsers and they work well
> >> with my UEFI secure boot patch, but I'm still looking for other options
> >> as well.
> >>
> >> * openssl
> >>   Most of existing components linked to UEFI secure boot, including
> >>   EDK2, shim and grub, reply on this library. Why not for U-Boot?
> >>   The size of U-Boot UEFI code in U-Boot is already quite big, and
> >>   so the size of openssl won't be a big issue.
> >> * mbedTLS
> >>   which is maintained by ARM and used with Zephyr, I guess it should
> >>   have small footprint. But it currently lacks pkcs7 parser.
> >>
> >> Any thoughts?
> > 
> > 
> > Paolo, Laszlo, Ard, if you could write a new secure boot implementation
> > today, which of the options above would you pick and why so? :)
> 
> Difficult question. Ideally you'd want a library where three aspects met:
> 
> - widely used (so that there is a diverse community that's interested in
> vulnerabilities, and fixing them too)
> 
> - easy to cross-compile for your free-standing environment (optimally
> the upstream project would support being cross-compiled and packaged
> stand-alone, for that free-standing environment)
> 
> - cares about API stability
> 
> OpenSSL is very widely used...
> ...and that's where we can stop in the list :)

It's also license-incompatible with U-Boot's GPLv2 I think.  I guess
grub can use it because GPLv3 and Apache v2 can be combined just fine.
Reusing Linux's code seems like the best match.

Paolo

[U-Boot] RSA in U-Boot

[Heinrich Schuchardt]

On 4/27/19 7:31 AM, Paolo Bonzini wrote:
>
>>>> I've done porting linux's pkcs7/x509 parsers and they work well
>>>> with my UEFI secure boot patch, but I'm still looking for other options
>>>> as well.
>>>>
>>>> * openssl
>>>>    Most of existing components linked to UEFI secure boot, including
>>>>    EDK2, shim and grub, reply on this library. Why not for U-Boot?
>>>>    The size of U-Boot UEFI code in U-Boot is already quite big, and
>>>>    so the size of openssl won't be a big issue.
>>>> * mbedTLS
>>>>    which is maintained by ARM and used with Zephyr, I guess it should
>>>>    have small footprint. But it currently lacks pkcs7 parser.
>>>>
>>>> Any thoughts?
>>>
>>>
>>> Paolo, Laszlo, Ard, if you could write a new secure boot implementation
>>> today, which of the options above would you pick and why so? :)
>>
>> Difficult question. Ideally you'd want a library where three aspects met:
>>
>> - widely used (so that there is a diverse community that's interested in
>> vulnerabilities, and fixing them too)
>>
>> - easy to cross-compile for your free-standing environment (optimally
>> the upstream project would support being cross-compiled and packaged
>> stand-alone, for that free-standing environment)
>>
>> - cares about API stability
>>
>> OpenSSL is very widely used...
>> ...and that's where we can stop in the list :)
>
> It's also license-incompatible with U-Boot's GPLv2 I think.  I guess
> grub can use it because GPLv3 and Apache v2 can be combined just fine.
> Reusing Linux's code seems like the best match.
>
> Paolo
>

You could have a look at GnuTLS available at
https://gitlab.com/gnutls/gnutls/ .

PKCS7 is supported, cf.
https://www.gnutls.org/manual/html_node/PKCS-7-API.html

There seem to be four main contributors to GnuTLS adding two patches a day:
https://github.com/gnutls/gnutls/graphs/contributors?from=2018-04-28&to=2019-04-27&type=a

Best regards

Heinrich

[U-Boot] RSA in U-Boot

[Sughosh Ganu]

On Sat, 27 Apr 2019 at 12:03, Heinrich Schuchardt <xypron.glpk@gmx.de>
wrote:

> On 4/27/19 7:31 AM, Paolo Bonzini wrote:
> >
> >>>> I've done porting linux's pkcs7/x509 parsers and they work well
> >>>> with my UEFI secure boot patch, but I'm still looking for other
> options
> >>>> as well.
> >>>>
> >>>> * openssl
> >>>>    Most of existing components linked to UEFI secure boot, including
> >>>>    EDK2, shim and grub, reply on this library. Why not for U-Boot?
> >>>>    The size of U-Boot UEFI code in U-Boot is already quite big, and
> >>>>    so the size of openssl won't be a big issue.
> >>>> * mbedTLS
> >>>>    which is maintained by ARM and used with Zephyr, I guess it should
> >>>>    have small footprint. But it currently lacks pkcs7 parser.
> >>>>
> >>>> Any thoughts?
> >>>
> >>>
> >>> Paolo, Laszlo, Ard, if you could write a new secure boot implementation
> >>> today, which of the options above would you pick and why so? :)
> >>
> >> Difficult question. Ideally you'd want a library where three aspects
> met:
> >>
> >> - widely used (so that there is a diverse community that's interested in
> >> vulnerabilities, and fixing them too)
> >>
> >> - easy to cross-compile for your free-standing environment (optimally
> >> the upstream project would support being cross-compiled and packaged
> >> stand-alone, for that free-standing environment)
> >>
> >> - cares about API stability
> >>
> >> OpenSSL is very widely used...
> >> ...and that's where we can stop in the list :)
> >
> > It's also license-incompatible with U-Boot's GPLv2 I think.  I guess
> > grub can use it because GPLv3 and Apache v2 can be combined just fine.
> > Reusing Linux's code seems like the best match.
> >
> > Paolo
> >
>
> You could have a look at GnuTLS available at
> https://gitlab.com/gnutls/gnutls/ .
>
> PKCS7 is supported, cf.
> https://www.gnutls.org/manual/html_node/PKCS-7-API.html
>
> There seem to be four main contributors to GnuTLS adding two patches a day:
>
> https://github.com/gnutls/gnutls/graphs/contributors?from=2018-04-28&to=2019-04-27&type=a


There is LibreSSL as well which is a fork of openssl. Guess that too should
be fine. What would be the more preferred solution here. The relevant bits
can be imported from the kernel code into u-boot, or there can be a
solution with linking of ssl/tls library with u-boot. Which would be the
more preferred solution. It'd be great if the maintainers can comment on
this. Thanks.

-sughosh

[U-Boot] RSA in U-Boot

[Wolfgang Denk]

Dear Sughosh Ganu,

In message <CADg8p96SiOJe+QT9-EUnrwW7FHiYp=w8PFQ7yUAoNb32aWEzHg@mail.gmail.com> you wrote:
> 
> There is LibreSSL as well which is a fork of openssl. Guess that too should
> be fine. What would be the more preferred solution here. The relevant bits
> can be imported from the kernel code into u-boot, or there can be a
> solution with linking of ssl/tls library with u-boot. Which would be the
> more preferred solution. It'd be great if the maintainers can comment on
> this. Thanks.

I'd go for the Linux kernel code.  A number of issues we have here
(cross compiling, code size, license compatibility, long term
maintenance efforts) have already been considered there, so why
should we duplicate all these efforts?  And if we did, is there any
clear benefit from doing this?

Just my 0,02€

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
Never underestimate the power of human stupidity  when  it  comes  to
using technology they don't understand.

[U-Boot] RSA in U-Boot

[Ilias Apalodimas]

On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
Hello Wolfgang, 

Thanks for taking the time with this
> > 
> > There is LibreSSL as well which is a fork of openssl. Guess that too should
> > be fine. What would be the more preferred solution here. The relevant bits
> > can be imported from the kernel code into u-boot, or there can be a
> > solution with linking of ssl/tls library with u-boot. Which would be the
> > more preferred solution. It'd be great if the maintainers can comment on
> > this. Thanks.
> 
> I'd go for the Linux kernel code.  A number of issues we have here
> (cross compiling, code size, license compatibility, long term
> maintenance efforts) have already been considered there, so why
> should we duplicate all these efforts?  And if we did, is there any
> clear benefit from doing this?
Well someone has to port the linux code in U-Boot and maintain it though.

The LibreSSL proposal was made with some of these in mind. 
We don't expect the licence to ever change (which is compatible) 
and it's being maintained. 
I am not sure on the portability status, but i think it runs on all major
architectures.

I'd imagine this lifts the maintenance burden from U-Boot. On the other 
hand we'll rely on an external library to offer the functionality. 

Regards
/Ilias

[U-Boot] RSA in U-Boot

[Tom Rini]

On Thu, May 16, 2019 at 01:45:54PM +0300, Ilias Apalodimas wrote:
> On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
> Hello Wolfgang, 
> 
> Thanks for taking the time with this
> > > 
> > > There is LibreSSL as well which is a fork of openssl. Guess that too should
> > > be fine. What would be the more preferred solution here. The relevant bits
> > > can be imported from the kernel code into u-boot, or there can be a
> > > solution with linking of ssl/tls library with u-boot. Which would be the
> > > more preferred solution. It'd be great if the maintainers can comment on
> > > this. Thanks.
> > 
> > I'd go for the Linux kernel code.  A number of issues we have here
> > (cross compiling, code size, license compatibility, long term
> > maintenance efforts) have already been considered there, so why
> > should we duplicate all these efforts?  And if we did, is there any
> > clear benefit from doing this?
> Well someone has to port the linux code in U-Boot and maintain it though.
> 
> The LibreSSL proposal was made with some of these in mind. 
> We don't expect the licence to ever change (which is compatible) 
> and it's being maintained. 
> I am not sure on the portability status, but i think it runs on all major
> architectures.
> 
> I'd imagine this lifts the maintenance burden from U-Boot. On the other 
> hand we'll rely on an external library to offer the functionality. 

I don't see how using LibreSSL instead of Linux kernel code would have a
lesser maintenance burden, sorry.  If anything, given the number of
parts of the code we have today that come from the Linux kernel, adding
one more to the "keep in sync, or at least port bugfixes" list is less
than "add a new external project to keep an eye on".

-- 
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/20190516/1bc3d083/attachment.sig>

[U-Boot] RSA in U-Boot

[Ilias Apalodimas]

Hi Tom,
> > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
> > Hello Wolfgang, 
> > 
> > Thanks for taking the time with this
> > > > 
> > > > There is LibreSSL as well which is a fork of openssl. Guess that too should
> > > > be fine. What would be the more preferred solution here. The relevant bits
> > > > can be imported from the kernel code into u-boot, or there can be a
> > > > solution with linking of ssl/tls library with u-boot. Which would be the
> > > > more preferred solution. It'd be great if the maintainers can comment on
> > > > this. Thanks.
> > > 
> > > I'd go for the Linux kernel code.  A number of issues we have here
> > > (cross compiling, code size, license compatibility, long term
> > > maintenance efforts) have already been considered there, so why
> > > should we duplicate all these efforts?  And if we did, is there any
> > > clear benefit from doing this?
> > Well someone has to port the linux code in U-Boot and maintain it though.
> > 
> > The LibreSSL proposal was made with some of these in mind. 
> > We don't expect the licence to ever change (which is compatible) 
> > and it's being maintained. 
> > I am not sure on the portability status, but i think it runs on all major
> > architectures.
> > 
> > I'd imagine this lifts the maintenance burden from U-Boot. On the other 
> > hand we'll rely on an external library to offer the functionality. 
> 
> I don't see how using LibreSSL instead of Linux kernel code would have a
> lesser maintenance burden, sorry.  If anything, given the number of
> parts of the code we have today that come from the Linux kernel, adding
> one more to the "keep in sync, or at least port bugfixes" list is less
> than "add a new external project to keep an eye on".
> 
Right then we know what we have to do. Kernel code it is. 

Thanks a lot 
/Ilias

[U-Boot] RSA in U-Boot

[AKASHI Takahiro]

Hi Tom,

On Thu, May 16, 2019 at 07:13:59AM -0400, Tom Rini wrote:
> On Thu, May 16, 2019 at 01:45:54PM +0300, Ilias Apalodimas wrote:
> > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
> > Hello Wolfgang, 
> > 
> > Thanks for taking the time with this
> > > > 
> > > > There is LibreSSL as well which is a fork of openssl. Guess that too should
> > > > be fine. What would be the more preferred solution here. The relevant bits
> > > > can be imported from the kernel code into u-boot, or there can be a
> > > > solution with linking of ssl/tls library with u-boot. Which would be the
> > > > more preferred solution. It'd be great if the maintainers can comment on
> > > > this. Thanks.
> > > 
> > > I'd go for the Linux kernel code.  A number of issues we have here
> > > (cross compiling, code size, license compatibility, long term
> > > maintenance efforts) have already been considered there, so why
> > > should we duplicate all these efforts?  And if we did, is there any
> > > clear benefit from doing this?
> > Well someone has to port the linux code in U-Boot and maintain it though.
> > 
> > The LibreSSL proposal was made with some of these in mind. 
> > We don't expect the licence to ever change (which is compatible) 
> > and it's being maintained. 
> > I am not sure on the portability status, but i think it runs on all major
> > architectures.
> > 
> > I'd imagine this lifts the maintenance burden from U-Boot. On the other 
> > hand we'll rely on an external library to offer the functionality. 
> 
> I don't see how using LibreSSL instead of Linux kernel code would have a
> lesser maintenance burden, sorry.  If anything, given the number of
> parts of the code we have today that come from the Linux kernel, adding
> one more to the "keep in sync, or at least port bugfixes" list is less
> than "add a new external project to keep an eye on".

# I will reply on this topic in more details tomorrow.

Can you give me an example of U-Boot code which comes from linux (or
other projects) and is regularly synced (or updated) with the origin?
Who maintains that? and how?

Thanks,
-Takahiro Akashi

> -- 
> Tom



> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] RSA in U-Boot

[Tom Rini]

On Thu, May 16, 2019 at 08:56:40PM +0900, AKASHI Takahiro wrote:
> Hi Tom,
> 
> On Thu, May 16, 2019 at 07:13:59AM -0400, Tom Rini wrote:
> > On Thu, May 16, 2019 at 01:45:54PM +0300, Ilias Apalodimas wrote:
> > > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
> > > Hello Wolfgang, 
> > > 
> > > Thanks for taking the time with this
> > > > > 
> > > > > There is LibreSSL as well which is a fork of openssl. Guess that too should
> > > > > be fine. What would be the more preferred solution here. The relevant bits
> > > > > can be imported from the kernel code into u-boot, or there can be a
> > > > > solution with linking of ssl/tls library with u-boot. Which would be the
> > > > > more preferred solution. It'd be great if the maintainers can comment on
> > > > > this. Thanks.
> > > > 
> > > > I'd go for the Linux kernel code.  A number of issues we have here
> > > > (cross compiling, code size, license compatibility, long term
> > > > maintenance efforts) have already been considered there, so why
> > > > should we duplicate all these efforts?  And if we did, is there any
> > > > clear benefit from doing this?
> > > Well someone has to port the linux code in U-Boot and maintain it though.
> > > 
> > > The LibreSSL proposal was made with some of these in mind. 
> > > We don't expect the licence to ever change (which is compatible) 
> > > and it's being maintained. 
> > > I am not sure on the portability status, but i think it runs on all major
> > > architectures.
> > > 
> > > I'd imagine this lifts the maintenance burden from U-Boot. On the other 
> > > hand we'll rely on an external library to offer the functionality. 
> > 
> > I don't see how using LibreSSL instead of Linux kernel code would have a
> > lesser maintenance burden, sorry.  If anything, given the number of
> > parts of the code we have today that come from the Linux kernel, adding
> > one more to the "keep in sync, or at least port bugfixes" list is less
> > than "add a new external project to keep an eye on".
> 
> # I will reply on this topic in more details tomorrow.
> 
> Can you give me an example of U-Boot code which comes from linux (or
> other projects) and is regularly synced (or updated) with the origin?
> Who maintains that? and how?

The device trees are one example.  Kbuild is another.  ubifs too.  We
just added lib/zstd :)

-- 
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/20190516/010072be/attachment.sig>

[U-Boot] RSA in U-Boot

[Wolfgang Denk]

Dear Akashi Takahiro,

In message <20190516115636.GA8052@fireball> you wrote:
> 
> Can you give me an example of U-Boot code which comes from linux (or
> other projects) and is regularly synced (or updated) with the origin?
> Who maintains that? and how?

Comes from Linux: a ton... Kconfig, Linker Script, MTD, UBI, UBIFS,
        ext2/3/4, jffs2, libfdt, many drivers, network stack,
        reiserfs, just to name a few.

Regularly synced: None.  Usually this only happens in irregular
	intervals, if incompatibilities or bugs (that have been
	fixed in more recent code) show up

Who: usually the responsible custodians

How: ideally thius should be a straightforward, though largely
	manual process.

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
Eureka!                                                 -- Archimedes

[U-Boot] RSA in U-Boot

[AKASHI Takahiro]

Tom, Wolfgang,

Thank you for your inputs.

On Thu, May 16, 2019 at 02:18:03PM +0200, Wolfgang Denk wrote:
> Dear Akashi Takahiro,
> 
> In message <20190516115636.GA8052@fireball> you wrote:
> > 
> > Can you give me an example of U-Boot code which comes from linux (or
> > other projects) and is regularly synced (or updated) with the origin?
> > Who maintains that? and how?
> 
> Comes from Linux: a ton... Kconfig, Linker Script, MTD, UBI, UBIFS,
>         ext2/3/4, jffs2, libfdt, many drivers, network stack,
>         reiserfs, just to name a few.
> 
> Regularly synced: None.  Usually this only happens in irregular
> 	intervals, if incompatibilities or bugs (that have been
> 	fixed in more recent code) show up
> 
> Who: usually the responsible custodians

"Custodians" don't always mean sub-system maintainers. Right?

> How: ideally thius should be a straightforward, though largely
> 	manual process.

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:

 cmd/Kconfig                       |    3 +
 include/crypto/internal/rsa.h     |   65 ++
 include/crypto/pkcs7.h            |   51 ++
 include/crypto/public_key.h       |   88 ++
 include/linux/asn1.h              |   69 ++
 include/linux/asn1_ber_bytecode.h |   93 +++
 include/linux/asn1_decoder.h      |   24 +
 include/linux/oid_registry.h      |  103 +++
 include/u-boot/rsa-mod-exp.h      |    3 +
 lib/Kconfig                       |   12 +
 lib/Makefile                      |   18 +
 lib/asn1_decoder.c                |  518 ++++++++++++
 lib/build_OID_registry            |  207 +++++
 lib/crypto/Kconfig                |   16 +
 lib/crypto/Makefile               |   38 +
 lib/crypto/pkcs7.asn1             |  135 ++++
 lib/crypto/pkcs7_parser.c         |  701 ++++++++++++++++
 lib/crypto/pkcs7_parser.h         |   69 ++
 lib/crypto/public_key.c           |  340 ++++++++
 lib/crypto/rsa_helper.c           |   81 ++
 lib/crypto/rsapubkey.asn1         |    4 +
 lib/crypto/x509.asn1              |   60 ++
 lib/crypto/x509_akid.asn1         |   35 +
 lib/crypto/x509_cert_parser.c     |  681 ++++++++++++++++
 lib/crypto/x509_parser.h          |   72 ++
 lib/crypto/x509_public_key.c      |  277 +++++++
 lib/oid_registry.c                |  170 ++++
 lib/rsa/Kconfig                   |    7 +
 lib/rsa/Makefile                  |    2 +-
 lib/rsa/rsa-keyprop.c             |  631 +++++++++++++++
 lib/rsa/rsa-verify.c              |   59 +-
 scripts/Makefile                  |    3 +
 scripts/Makefile.build            |    6 +-
 scripts/asn1_compiler.c           | 1615 +++++++++++++++++++++++++++++++++++++
 scripts/linux/asn1.h              |   69 ++
 scripts/linux/asn1_ber_bytecode.h |   93 +++
 tools/Makefile                    |    2 +
 37 files changed, 6409 insertions(+), 11 deletions(-)

My modification is not yet optimized to keep updates much easier,
but those numbers will give you a rough idea.

Thanks,
-Takahiro Akashi

[U-Boot] RSA in U-Boot

[Wolfgang Denk]

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.

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

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.

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

[U-Boot] RSA in U-Boot

[AKASHI Takahiro]

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

[U-Boot] RSA in U-Boot

[AKASHI Takahiro]

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

Thanks,
-Takahiro Akashi


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

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

[U-Boot] RSA in U-Boot

[Grant Likely]

Hi Takahiro,

On 17/05/2019 01:12, AKASHI Takahiro wrote:
[...]
> In fact, I have already imported relevant kernel code into U-Boot
> and it now works perfectly with my experimental UEFI secure boot patch,

Speaking of which, where can I find the experimental UEFI secure boot 
patches? I've not been able to find any recent postings.

Thanks,
g.

[U-Boot] RSA in U-Boot

[AKASHI Takahiro]

Hi Grant,

On Tue, Aug 27, 2019 at 10:35:37AM +0000, Grant Likely wrote:
> Hi Takahiro,
> 
> On 17/05/2019 01:12, AKASHI Takahiro wrote:
> [...]
> > In fact, I have already imported relevant kernel code into U-Boot
> > and it now works perfectly with my experimental UEFI secure boot patch,
> 
> Speaking of which, where can I find the experimental UEFI secure boot 
> patches? I've not been able to find any recent postings.

Here's my repository:
https://git.linaro.org/people/takahiro.akashi/u-boot.git efi/secboot

But it's quite old and not ready for public review, yet it works in some way.
Since then, I've done
- implementing image authentication as close to EDK2's semantics as possible,
  including timestamp-based revocation
- improving portability of linux-kernel-based pkcs7/x509 parsers
- reworking the code in general for better maintainability
- adding initial automated testing of image/variable authentication
  based on pytest framework

On the other hand, Sughosh and Pipat are working on integrating
StMM-based UEFI variables/secure storage into U-Boot.

As far as my part is concerned, my plan is that I will focus on developing
more test cases and verifying the authentication code. Once I have some good
confidence, I'd like to submit the patch set.
It will be around the next Connect, I guess?

Thanks,
-Takahiro Akashi


> Thanks,
> g.

[U-Boot] RSA in U-Boot

[Paolo Bonzini]

On 16/05/19 09:23, Sughosh Ganu wrote:
> 
>     > It's also license-incompatible with U-Boot's GPLv2 I think.  I guess
>     > grub can use it because GPLv3 and Apache v2 can be combined just fine.
>     > Reusing Linux's code seems like the best match.
>     >
>     > Paolo
>     >
> 
>     You could have a look at GnuTLS available at
>     https://gitlab.com/gnutls/gnutls/ .
> 
>     PKCS7 is supported, cf.
>     https://www.gnutls.org/manual/html_node/PKCS-7-API.html
> 
>     There seem to be four main contributors to GnuTLS adding two patches
>     a day:
>     https://github.com/gnutls/gnutls/graphs/contributors?from=2018-04-28&to=2019-04-27&type=a
> 
> 
> There is LibreSSL as well which is a fork of openssl. Guess that too
> should be fine.

LibreSSL has the same license issue (i.e. it's GPLv3-compatible but
GPLv2-incompatible) as OpenSSL.

Paolo

[U-Boot] RSA in U-Boot

[AKASHI, Takahiro]

Thank all of you who commented on my question.

@Laszlo, I agree to the criteria that you mentioned.
	good user base is a crucial factor for security code.

@Paolo, I have had no idea about license term issues. You're right.

@Heinrich, thank you for pointing out gnutls. I'm stilling looking
	into the code, but my first impression is that it is not
	well optimized for *smaller* system.

@Sughosh, as Paolo mentioned, LibreSSL may have a similar license issue:
	The license term seems to be a variant of 3-clause BSD, and some
	file header says,
 * The licence and distribution terms for any publically available version or
 * derivative of this code cannot be changed.  i.e. this code cannot simply be
 * copied and put under another distribution licence
 * [including the GNU Public Licence.]

Thanks,
-Takahiro Akashi

On Fri, Apr 26, 2019 at 11:05:27AM +0200, Alexander Graf wrote:
> 
> On 25.04.19 04:12, AKASHI, Takahiro wrote:
> > Update and reminder.
> >
> > On Mon, Mar 18, 2019 at 11:17:14AM +0900, AKASHI, Takahiro wrote:
> >> Hi,
> >>
> >> I'd like to discuss this topic in public.
> >> I will appreciate your comments here.
> >> # FYI, I now started to experimentally port linux's pkcs7/x509
> >> # parser.
> > I've done porting linux's pkcs7/x509 parsers and they work well
> > with my UEFI secure boot patch, but I'm still looking for other options
> > as well.
> >
> > * openssl
> >   Most of existing components linked to UEFI secure boot, including
> >   EDK2, shim and grub, reply on this library. Why not for U-Boot?
> >   The size of U-Boot UEFI code in U-Boot is already quite big, and
> >   so the size of openssl won't be a big issue.
> > * mbedTLS
> >   which is maintained by ARM and used with Zephyr, I guess it should
> >   have small footprint. But it currently lacks pkcs7 parser.
> >
> > Any thoughts?
> 
> 
> Paolo, Laszlo, Ard, if you could write a new secure boot implementation
> today, which of the options above would you pick and why so? :)
> 
> 
> Thanks,
> 
> Alex
> 
> 
> >
> > Thanks,
> > -Takahiro Akashi
> >
> >
> >> Thanks,
> >> -Takahiro Akashi
> >>
> >> ----- Forwarded message from Simon Glass <sjg@chromium.org> -----
> >>
> >> Date: Thu, 7 Mar 2019 19:56:10 -0700
> >> From: Simon Glass <sjg@chromium.org>
> >> To: "AKASHI, Takahiro" <takahiro.akashi@linaro.org>
> >> Subject: Re: RSA in U-Boot
> >>
> >> Hi Takahiro,
> >>
> >> On Thu, 7 Mar 2019 at 17:27, AKASHI, Takahiro
> >> <takahiro.akashi@linaro.org> wrote:
> >>> Hi Simon,
> >>>
> >>> Before I start discussions publicly, I'd like to hear
> >>> your opinion first.
> >> I do think it is better to discuss this in public since there will be
> >> other opinions.
> >>
> >>> I'm now working on implementing "secure boot"
> >>> for UEFI U-Boot.
> >>>
> >>> As you might know, there are a couple of features
> >>> required to achieve "secure boot":
> >>> (I won't discuss about secure storage here though.)
> >>> - x509 certificate decoder
> >>> - pkcs7 decoder (for PE file's signature)
> >>> - RSA verification
> >>> - (hash digest, sha256)
> >>>
> >>> The original code, which was written by some other guy,
> >>> Patrick, uses BearSSL for x509 and RSA and
> >>> I'm now wondering what is the best solution.
> >>> Obviously, I can think of several options here:
> >>> 1. use BearSSL
> >>>   1.a just import minimum set of files akin lib/libfdt
> >>>   1.b link whole BearSSL as a library, merging the code
> >>>         as git submodule
> >>> 2. use openssl
> >>> 3. import linux kernel code, particularly x509 & pkcs7 parser
> >>> 4. write our own code
> >>>
> >>> I suppose that you weighed similar choices when you implemented
> >>> "FIT image signing".
> >>> Can you share your opinion with me?
> >> I think if you can do 3 then it keeps U-Boot self-contained and
> >> perhaps provides for simple code. That said, if the amount of code is
> >> large and has an upstream there is clear precident for 1a, as you say.
> >>
> >> I am not sure about 4. If it is a relatively small amount of code,
> >> then maybe, but surely it makes sense to use the linux code where
> >> possible. That is what I did with the U-Boot livetree code.
> >>
> >> 1b sounds painful to me.
> >>
> >>> Regarding your lib/rsa code, you intentionally avoided to
> >>> add formula of inverse-mod and power-mod of R. Do you still
> >>> believe that the assumption is appropriate?
> >>> (BearSSL implements its own montgomery.
> >> If you look at a talk I gave on this, you can see that one of the
> >> goals was to implement it efficiently, with minimal extra code at
> >> run-time, and minimal memory usage. So unpacking complex key
> >> structures did not seem like a good idea. From memory you can do
> >> verified boot in about 7KB of extra code in U-Boot and it runs in a
> >> small number of milliseconds.
> >>
> >> UEFI is obviously pretty big, so perhaps efficiency concerns are less
> >> important. More important probably is wide compatibility, supporting
> >> all possible options, etc.
> >>
> >> I hope this is helpful.
> >>
> >> Regards,
> >> Simon
> >>
> >> ----- End forwarded message -----