Re: [edk2-devel] [PATCH 0/5] CryptoPkg/openssl: enable EC unconditionally.

["James Bottomley" <James.Bottomley@HansenPartnership.com>]

On Tue, 2022-05-10 at 12:40 +0200, Gerd Hoffmann wrote:
> On Mon, May 09, 2022 at 09:41:02AM -0400, James Bottomley wrote:
> > On Mon, 2022-05-09 at 12:03 +0000, Yao, Jiewen wrote:
> > > It is possible to switch to other crypt lib.
> > > 
> > > For example, the *mbedtls* version POC can be found at 
> > > https://github.com/jyao1/edk2/tree/DeviceSecurity/CryptoMbedTlsPkg
> > > The advantage is: the size is much smaller.
> > > The disadvantage is: some required functions are not available,
> > > such as PKCS7. 
> > 
> > Perhaps as a first step, we should look at our options.  I would
> > say missing functionality is problematic, but not necessarily a
> > killer: we'd have to help the chosen project develop the capability
> > and figure out how to maintain the fork while it was going
> > upstream.
> 
> I don't feel like entering the business of maintaining a tls
> library ...

Me neither, but we already maintain some exceptions like the logic to
break the X509 chain for UEFI, so if we had to tinker around the edges,
I think it's feasible.

> > Other libraries could be:
> > 
> > wolfssl
> 
> Hmm?  Apparently no git repository?

https://github.com/wolfSSL/wolfssl

> > gnutls
> 
> Might be a issue license-wise.

It's LGPL and our use case entirely embeds it so we're using it within
the licence terms.  Since we're effectively linking statically, it
provides a slight problem for distributions because they need to
facilitate relinking, but that's just a nasty mechanical problem

> 
> > boringssl
> 
> Looks like an option worth investigating.
> 
> The "designed to meet Google's needs" and "not intended for general
> use" notes in the toplevel README don't look that great
> though.  Might turnons out to be be difficult to get changes needed
> for edk2 merged (hasn't been a problem so far for me with openssl).

Right, boringssl is effectively Google's fork of openssl for android
which they did because they could never get the openssl people to
accept their patches or pay attention to the embedded bloat problem
(which is currently our problem).

> > LibreSSL
> 
> There was some hype around it after it was forked from openssl in the
> heartbleed aftermath.  More recent news are less enthusiastic:
> https://lwn.net/Articles/841664/

Yes, I'm not hugely enthused about LibreSSL, but I think we do need to
list all the alternatives.

> Another possible option would be to add openssl3 as alternative
> OpensslLib implementation, so platforms can pick the one or the
> other depending on size constrains.

Really, no, we can't.  That would leave the space constrained use case
non functional when openssl 1 goes EOL.  We have to make openssl 3 work
for everything or consider a new crypto provider.

> I've also experimented a bit with CryptoPkg/Driver.  It's not a
> clear win, at least for OVMF.
> 
> PEI FV is larger in any case.  Seems LTO works very well for the
> few hashes needed by TPM support code, and so the overhead added
> by using the crypto service protocol instead of direct linking is
> much larger than the savings by sharing code.
> 
> DXE FV is smaller in the builds with secure boot and smm support,
> seems with the large tls codebase included we have enough wins by
> sharing the crypto code then, so the protocol overhead is worth
> the effort.
> 
> I'm wondering where the crypto algorithm selection in
> CryptoPkg/CryptoPkg.dsc comes from though, specifically for
> MIN_DXE_MIN_SMM.  Why is the crypto feature selection identical
> for DXE and SMM?  Specifically why TLS is enabled for SMM?

I think the idea was that using a static openssl library you could link
the various algorithm providers with it and make small pieces, but that
didn't work out well for openssl which has a massive startup
requirement.  No idea why SMM would require TLS ... I can look at the
code.

James