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 <s...@chromium.org> ----- >> >> Date: Thu, 7 Mar 2019 19:56:10 -0700 >> From: Simon Glass <s...@chromium.org> >> To: "AKASHI, Takahiro" <takahiro.aka...@linaro.org> >> Subject: Re: RSA in U-Boot >> >> Hi Takahiro, >> >> On Thu, 7 Mar 2019 at 17:27, AKASHI, Takahiro >> <takahiro.aka...@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 mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot