From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) by mx.groups.io with SMTP id smtpd.web09.30850.1652096865354195760 for ; Mon, 09 May 2022 04:47:45 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=kl6/Lf3r; spf=pass (domain: hansenpartnership.com, ip: 96.44.175.130, mailfrom: james.bottomley@hansenpartnership.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1652096864; bh=RXkSPI2QOb2vmY7it7Qh2d8ti5Le4PcgTVOm2uxijsM=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=kl6/Lf3rsuWLn10ZNZDiCl/OB3N0215kWbTk+iyOnYipT6cc7JbEVVliydyhjcZEZ S7qVJOrcP/17ikib3QS37DJH7LvRxowtJexq7JVmnnOO3icMpmSfeDsPB1rucDSdfi +RU+53EeXcyqc8YsOdqN5n6n1b3LI8/cKEk31h2U= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 231D51280CDA; Mon, 9 May 2022 07:47:44 -0400 (EDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbzkWQ32KDpl; Mon, 9 May 2022 07:47:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1652096863; bh=RXkSPI2QOb2vmY7it7Qh2d8ti5Le4PcgTVOm2uxijsM=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=v6WEljUEKyIYdd64w/a80S0UgmQwEwrIeR9t8LKSn213s8HGwSHWdfxo05Pigkyer jguHYk1O2Sq+FsCcohPBLzya5RFRqnsbQJGEsSj5sHaSXnBEXXKahABDbFwUdwM+OZ teG3z+dunX+dMGoOCMuRtnGDm1UauHvnIeblw6Vs= Received: from [IPv6:2601:5c4:4300:c551:a71:90ff:fec2:f05b] (unknown [IPv6:2601:5c4:4300:c551:a71:90ff:fec2:f05b]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id C5B301280B51; Mon, 9 May 2022 07:47:42 -0400 (EDT) Message-ID: <97444089e5113f5b5c5f538635ff1821f1c62cb2.camel@HansenPartnership.com> Subject: Re: [edk2-devel] [PATCH 0/5] CryptoPkg/openssl: enable EC unconditionally. From: "James Bottomley" To: devel@edk2.groups.io, kraxel@redhat.com, "Yao, Jiewen" Cc: Pawel Polawski , "Li, Yi1" , Oliver Steffen , "Wang, Jian J" , Ard Biesheuvel , "Jiang, Guomin" , "Lu, Xiaoyu1" , "Justen, Jordan L" Date: Mon, 09 May 2022 07:47:41 -0400 In-Reply-To: <20220509112744.msdph5d35ph24l4p@sirius.home.kraxel.org> References: <20220502103436.3274412-1-kraxel@redhat.com> <20220505080638.rmrw3f773rkw3ljl@sirius.home.kraxel.org> <20220505091536.llguh4dzozqtiiob@sirius.home.kraxel.org> <20220509094511.px6cl7jtjejr4y4x@sirius.home.kraxel.org> <20220509112744.msdph5d35ph24l4p@sirius.home.kraxel.org> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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