From mboxrd@z Thu Jan 1 00:00:00 1970 From: AKASHI Takahiro Date: Wed, 22 May 2019 14:48:42 +0900 Subject: [U-Boot] RSA in U-Boot In-Reply-To: <20190517084756.507E1240014@gemini.denx.de> References: <422971965.15677087.1556343097301.JavaMail.zimbra@redhat.com> <4b32b851-181e-5846-c5b0-17cadae06f33@gmx.de> <20190516103902.C27F1245E45@gemini.denx.de> <20190516104554.GA15680@apalos> <20190516111359.GQ22232@bill-the-cat> <20190516115636.GA8052@fireball> <20190516121803.C6216245E45@gemini.denx.de> <20190517001206.GX11160@linaro.org> <20190517084756.507E1240014@gemini.denx.de> Message-ID: <20190522054840.GC28505@linaro.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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