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 (#89651): https://edk2.groups.io/g/devel/message/89651 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] -=-=-=-=-=-=-=-=-=-=-=-
