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

Yao, Jiewen jiewen.yao at intel.com
Tue May 10 11:20:46 UTC 2022


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

[Jiewen] So far, I don't know if any SMM feature requires TLS.

I guess we may win the flash size by creating identical binary for CryptoDxe and CryptoSmm *with compression*. But I don't have data and I am not sure. Just guess.

You may have a try to remove TLS for SMM and check the final compressed FV size.




> -----Original Message-----
> From: kraxel at redhat.com <kraxel at redhat.com>
> Sent: Tuesday, May 10, 2022 6:40 PM
> To: James Bottomley <James.Bottomley at hansenpartnership.com>
> Cc: devel at edk2.groups.io; Yao, Jiewen <jiewen.yao at intel.com>; Pawel
> Polawski <ppolawsk at redhat.com>; Li, Yi1 <yi1.li at intel.com>; Oliver Steffen
> <osteffen at redhat.com>; Wang, Jian J <jian.j.wang at intel.com>; Ard Biesheuvel
> <ardb+tianocore at kernel.org>; Jiang, Guomin <guomin.jiang at intel.com>; Lu,
> Xiaoyu1 <xiaoyu1.lu at intel.com>; Justen, Jordan L <jordan.l.justen at intel.com>
> Subject: Re: [edk2-devel] [PATCH 0/5] CryptoPkg/openssl: enable EC
> unconditionally.
> 
> 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



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89653): https://edk2.groups.io/g/devel/message/89653
Mute This Topic: https://groups.io/mt/90832153/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-




More information about the edk2-devel-archive mailing list