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

["Yao, Jiewen" <jiewen.yao@intel.com>]

I am not sure how good the openssl MACRO is designed to remove unnecessary crypto.

I think we may submit patch to openssl to add more configuration, if that can help reduce size.

Thank you
Yao Jiewen


> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao, Jiewen
> Sent: Monday, May 9, 2022 8:03 PM
> To: devel@edk2.groups.io; James.Bottomley@HansenPartnership.com;
> kraxel@redhat.com
> Cc: Pawel Polawski <ppolawsk@redhat.com>; Li, Yi1 <yi1.li@intel.com>; Oliver
> Steffen <osteffen@redhat.com>; Wang, Jian J <jian.j.wang@intel.com>; Ard
> Biesheuvel <ardb+tianocore@kernel.org>; Jiang, Guomin
> <guomin.jiang@intel.com>; Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>; Justen, Jordan
> L <jordan.l.justen@intel.com>
> Subject: Re: [edk2-devel] [PATCH 0/5] CryptoPkg/openssl: enable EC
> unconditionally.
> 
> 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.
> 
> Thank you
> Yao Jiewen
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of James
> > Bottomley
> > Sent: Monday, May 9, 2022 7:48 PM
> > To: devel@edk2.groups.io; kraxel@redhat.com; Yao, Jiewen
> > <jiewen.yao@intel.com>
> > Cc: Pawel Polawski <ppolawsk@redhat.com>; Li, Yi1 <yi1.li@intel.com>;
> Oliver
> > Steffen <osteffen@redhat.com>; Wang, Jian J <jian.j.wang@intel.com>; Ard
> > Biesheuvel <ardb+tianocore@kernel.org>; Jiang, Guomin
> > <guomin.jiang@intel.com>; Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>; Justen,
> Jordan
> > L <jordan.l.justen@intel.com>
> > Subject: Re: [edk2-devel] [PATCH 0/5] CryptoPkg/openssl: enable EC
> > unconditionally.
> >
> > On Mon, 2022-05-09 at 13:27 +0200, Gerd Hoffmann wrote:
> > [...]
> > > > 1) Please keep the good work to enable OPENSSL3.0 in your personal
> > > > branch.
> > > > 2) If you have some way to control the size, then do it. If there
> > > > is no much size difference by default, then you can submit to EDKII
> > > > directly.
> > >
> > > I suspect I wouldn't get it down to 1.1.1 levels even if I find some
> > > ways to make it smaller than it is in my branch today.  The code for
> > > the new "provider" concept simply needs space and I think it also
> > > makes LTO optimization less effective.
> >
> > Having just looked into converting engine code to provider code, I
> > would concur with this.  The design of providers, with their many to
> > many functional mappings, seems designed to promote code bloat.
> >
> > > Maybe creating our own crypto providers which include only the
> > > algorithms actually needed by edk2 gets the size down a bit.
> >
> > What about switching to a different crypto backend?  Since we don't
> > expose any openssl APIs at all and we wrapper everything we do expose,
> > it should be possible to switch to one of the non-openssl (or forked
> > from openssl) variants that value size, like mbedtls or boringssl?
> >
> > James
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
>