> 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: kra...@redhat.com <kra...@redhat.com> > Sent: Tuesday, May 10, 2022 6:40 PM > To: James Bottomley <james.bottom...@hansenpartnership.com> > Cc: devel@edk2.groups.io; Yao, Jiewen <jiewen....@intel.com>; Pawel > Polawski <ppola...@redhat.com>; Li, Yi1 <yi1...@intel.com>; Oliver Steffen > <ostef...@redhat.com>; Wang, Jian J <jian.j.w...@intel.com>; Ard Biesheuvel > <ardb+tianoc...@kernel.org>; Jiang, Guomin <guomin.ji...@intel.com>; Lu, > Xiaoyu1 <xiaoyu1...@intel.com>; Justen, Jordan L <jordan.l.jus...@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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
