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

["Gerd Hoffmann" <kraxel@redhat.com>]

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

> Other libraries could be:
> 
> wolfssl

Hmm?  Apparently no git repository?

> gnutls

Might be a issue license-wise.

> 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 turn
out to be be difficult to get changes needed for edk2 merged (hasn't
been a problem so far for me with openssl).

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

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.


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?

take care,
  Gerd