Re: [edk2-devel] [PATCH 00/11] OvmfPkg: add Crypto Driver support

["Ard Biesheuvel" <ardb@kernel.org>]

On Fri, 3 Feb 2023 at 17:28, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>   Hi,
>
> > > Unfortunately it is not a clear size win everywhere.
> > >
> > > PEI jumps up in size even though I'm using the min_pei config for
> > > CryptoPei, seems it *still* has way too much bits compiled in
> > > (didn't look into tweaking the config yet, hints are welcome).
> > >
> > > -   17530 TcgPei
> > > +   17146 TcgPei
> > > +   34362 Tcg2Pei
> > > -   51066 Tcg2Pei
> > > +  333950 CryptoPei
> >
> > Why would we use this for PEI if the size increases?
>
> When using the crypto driver I'd prefer to do it everywhere and
> don't mix+match things.
>
> Background is that I'm hoping the crypto driver abstraction can also
> help to have alternative drivers using other crypto libraries without
> creating a huge mess in CryptoPkg.  Specifically add openssl-3 as an
> option.  openssl-11 goes EOL later this year (Nov IIRC).  Switch to
> openssl-3 unconditionally has been vetoed by Intel due to the size
> increase v3 brings.  So I'm looking for options here ...
>

I agree that this is a good idea in principle. However, the TPM code
probably just uses a few flavors of SHA and nothing else, and this is
not the part of CryptoPkg that I'd be concerned about. Most of the
issues with OpenSSL are in the TLS part of the library, with the
insanely complex ASN.1 parsing and X.509 handling etc etc.

Could we build CryptoPei with fewer algorithms built into it?

> > > If there are no objections I happily drop the USE_CRYPTO_DRIVER option
> > > and switch over to the crypto driver unconditionally.
> >
> > Yeah, I'd prefer that.
>
> Noted for v2 next week.
>
> take care,
>   Gerd
>