From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web08.8071.1652179209488462527 for ; Tue, 10 May 2022 03:40:10 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NmuycTi3; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1652179208; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dDokEMzwaWOK7ycYTILd5LucS5eTP2TniR/g9lgL2z8=; b=NmuycTi310HL9OBrItFW1NlA5CaHkT5p2N4B2dXqKKDe+Ysdwu82LpuuxGs1wB3xbXP35Z 04yzgVNRkHMn7rV6mIhgAZUJBzTgQ7el4ufqkQ0yBSL+M52hScXMZs7kv4ola97DcuPn2f +X6hK2U6xC765iGSy9SdGkJg4pgbmdk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-141-s-C67KYFPRaHgEpheAYuBA-1; Tue, 10 May 2022 06:40:05 -0400 X-MC-Unique: s-C67KYFPRaHgEpheAYuBA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A186A811E75; Tue, 10 May 2022 10:40:04 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.195.194]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8EB851468F31; Tue, 10 May 2022 10:40:03 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 6025F18000A3; Tue, 10 May 2022 12:40:01 +0200 (CEST) Date: Tue, 10 May 2022 12:40:01 +0200 From: "Gerd Hoffmann" To: James Bottomley Cc: devel@edk2.groups.io, jiewen.yao@intel.com, Pawel Polawski , "Li, Yi1" , Oliver Steffen , "Wang, Jian J" , Ard Biesheuvel , "Jiang, Guomin" , "Lu, Xiaoyu1" , "Justen, Jordan L" Subject: Re: [edk2-devel] [PATCH 0/5] CryptoPkg/openssl: enable EC unconditionally. Message-ID: <20220510104001.rqddxn53euydk2ns@sirius.home.kraxel.org> References: <20220505080638.rmrw3f773rkw3ljl@sirius.home.kraxel.org> <20220505091536.llguh4dzozqtiiob@sirius.home.kraxel.org> <20220509094511.px6cl7jtjejr4y4x@sirius.home.kraxel.org> <20220509112744.msdph5d35ph24l4p@sirius.home.kraxel.org> <97444089e5113f5b5c5f538635ff1821f1c62cb2.camel@HansenPartnership.com> <98f4a21f4ce5cb50331177dd8b6aa53dc932561b.camel@HansenPartnership.com> MIME-Version: 1.0 In-Reply-To: <98f4a21f4ce5cb50331177dd8b6aa53dc932561b.camel@HansenPartnership.com> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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