[U-Boot] RSA in U-Boot
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:
- 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 -----
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:
- 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 -----
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:
- 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 -----
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:
- 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 -----
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
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=...
Best regards
Heinrich
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=...
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
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
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
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".
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
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@lists.denx.de https://lists.denx.de/listinfo/u-boot
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 :)
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
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
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
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@denx.de miracle: an extremely outstanding or unusual event, thing, or accomplishment. - Webster's Dictionary
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@denx.de miracle: an extremely outstanding or unusual event, thing, or accomplishment. - Webster's Dictionary
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.
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.
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.
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=aThere 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
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:
- 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 -----
participants (11)
-
AKASHI Takahiro -
AKASHI, Takahiro
-
Alexander Graf -
Grant Likely -
Heinrich Schuchardt -
Ilias Apalodimas -
Laszlo Ersek -
Paolo Bonzini -
Sughosh Ganu -
Tom Rini -
Wolfgang Denk