From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mx.groups.io with SMTP id smtpd.web11.6149.1585288235285451820 for ; Thu, 26 Mar 2020 22:50:35 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.151, mailfrom: jiewen.yao@intel.com) IronPort-SDR: VADpuM25x6Q9uQZ6HYXXXGs3MCErwKjr+J/brtUvzyiVvPVNofwr53rjFjONCKv6GMP0x/C5Zb MukHnx26UfTQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2020 22:50:34 -0700 IronPort-SDR: voqx2ZiW/q/3NB/3QWYDMoo0+Zobe2Y77DXsqbgGTn/SIhbovIhRSadV93JLkH+B82qdVwkKqi ZZstZLA1qK0g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,311,1580803200"; d="scan'208";a="394273205" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga004.jf.intel.com with ESMTP; 26 Mar 2020 22:50:34 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 26 Mar 2020 22:50:34 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 26 Mar 2020 22:50:33 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 26 Mar 2020 22:50:33 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.50]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.201]) with mapi id 14.03.0439.000; Fri, 27 Mar 2020 13:50:31 +0800 From: "Yao, Jiewen" To: "Fu, Siyuan" , "devel@edk2.groups.io" , "Gao, Zhichao" CC: "Wang, Jian J" , "Lu, XiaoyuX" , Maciej Rabeda , "Wu, Jiaxin" Subject: Re: [edk2-devel] [PATCH 0/8] CryptoPkg: Retire the deprecate function Thread-Topic: [edk2-devel] [PATCH 0/8] CryptoPkg: Retire the deprecate function Thread-Index: AQHWA9r3vfbc0WLdPUSI70pQ90E/bahbNjmAgACIDrD//31yAIAAhwdg//+ktQCAAIbe8A== Date: Fri, 27 Mar 2020 05:50:30 +0000 Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503F9A0BBF@shsmsx102.ccr.corp.intel.com> References: <20200327015629.2588-1-zhichao.gao@intel.com> <74D8A39837DF1E4DA445A8C0B3885C503F9A0490@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503F9A08EF@shsmsx102.ccr.corp.intel.com> In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: jiewen.yao@intel.com Content-Language: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Siyuan If you are just talking *private interface*, it is OK. My concern is raised, when you say: we cannot change a private protocol. That means, we have to keep the ugly interface forever. :-( I am feeling there is some wrong fundamentally. My believe is: If it is private, we can change. If we cannot change, it is not private. Thank you Yao Jiewen > -----Original Message----- > From: Fu, Siyuan > Sent: Friday, March 27, 2020 1:43 PM > To: Yao, Jiewen ; devel@edk2.groups.io; Gao, Zhich= ao > > Cc: Wang, Jian J ; Lu, XiaoyuX ; > Maciej Rabeda ; Wu, Jiaxin > > Subject: RE: [edk2-devel] [PATCH 0/8] CryptoPkg: Retire the deprecate fu= nction >=20 > Jiewen, >=20 > I agree "abstract action not algorithm" is a good design principle, but = I'm not > sure > If there is any plan to move this protocol to the public include so far. > For this patch set, my feeling is it should at least do not modify the e= xisting > protocol definition, so the modulization update capability won't be brok= en. > I'm also welcome to see if the protocol can be enhanced as you mentioned > below. >=20 > Best Regards > Siyuan >=20 > > -----Original Message----- > > From: Yao, Jiewen > > Sent: 2020=1B$BG/=1B(B3=1B$B7n=1B(B27=1B$BF|=1B(B 12:59 > > To: Fu, Siyuan ; devel@edk2.groups.io; Gao, Zhich= ao > > > > Cc: Wang, Jian J ; Lu, XiaoyuX > ; > > Maciej Rabeda ; Wu, Jiaxin > > > > Subject: RE: [edk2-devel] [PATCH 0/8] CryptoPkg: Retire the deprecate > function > > > > Thanks Siyun. > > I think probably we need discuss this more. > > > > 1) About private v.s. public. > > > > The benefit for private include is to isolate external interface and i= nternal > > interface. > > A package can keep updating its private interface without impact any o= ther > > packages. > > However, in this case, a private interface update will bring binary co= mpatibility > > issue with other package. > > I am not sure it is acceptable or not. > > > > Mike > > Do you have any comment? Is that the design goal of private interface = - just > > keep source code compatibility, but not binary compatiblity? > > > > 2) About the protocol itself. > > > > One concern I have is that we *hardcode* the algorithm in protocol. > > > > We keeps adding new algorithm and removing old one. That means this > protocol > > interface is unstable. > > > > Today, we have defined SHA2 set, and deprecating SHA1 and older one. > > Tomorrow we may need add SHA3 set. > > Today, we have RSAPKCS1_15. Tomorrow we will have RSAPSS. > > Some other new set of algorithms might be added later, such as AEAD, G= MAC. > > > > For a protocol definition, I think we need *abstract the action*, but = not > > *algorithm*. > > One good example is the UEFI HASH2 Protocol. > > > https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Ha= s > > h2.h > > It just tells you do the hash. You may add new algorithm GUID. > > > > Another good example is inside of openssl. Now it is using EVP style c= ipher > algo. > > For example, > > https://www.openssl.org/docs/man1.1.1/man3/EVP_EncryptInit_ex.html > > https://www.openssl.org/docs/man1.1.0/man3/EVP_CIPHER_CTX_ctrl.html > > The cipher itself is input as parameter. > > > > The benefit is that, if we want to deprecate an algorithm, the interfa= ce can be > > unchanged. > > Just the internal implementation can be changed. > > The current PCD mechanism can still be applied to internal implementat= ion. > > > > Can we get a chance to revisit/redesign the protocol API, when we move= to > > public include? > > > > Thank you > > Yao Jiewen > > > > > -----Original Message----- > > > From: Fu, Siyuan > > > Sent: Friday, March 27, 2020 11:07 AM > > > To: Yao, Jiewen ; devel@edk2.groups.io; Gao, > > Zhichao > > > > > > Cc: Wang, Jian J ; Lu, XiaoyuX > > ; > > > Maciej Rabeda ; Wu, Jiaxin > > > > > > Subject: RE: [edk2-devel] [PATCH 0/8] CryptoPkg: Retire the deprecat= e > > function > > > > > > Hi, Jiewen > > > > > > Although the protocol is private, a corresponding BaseCryptoLib inst= ance is > > > not private, like PeiCryptLib.inf, RuntimeCryptLib, etc. These libra= ry instances > > > will be static linked to the consumer driver, for example an iSCSI n= etwork > > driver. > > > So actually it's not a "private" change inside CryptoPkg. > > > > > > The goal to provide a driver version of crypto service is to support > > modulization > > > FW update, which means the crypto driver may NOT be updated together > with > > > its consumer. A platform may choose to update the crypto service dri= ver to a > > > new version with this patch, then all the BaseCryptoLib consumers wi= ll be > > > messed. > > > > > > Best Regards > > > Siyuan > > > > > > > -----Original Message----- > > > > From: Yao, Jiewen > > > > Sent: 2020=1B$BG/=1B(B3=1B$B7n=1B(B27=1B$BF|=1B(B 10:58 > > > > To: devel@edk2.groups.io; Fu, Siyuan ; Gao, > Zhichao > > > > > > > > Cc: Wang, Jian J ; Lu, XiaoyuX > > > ; > > > > Maciej Rabeda ; Wu, Jiaxin > > > > > > > > Subject: RE: [edk2-devel] [PATCH 0/8] CryptoPkg: Retire the deprec= ate > > > function > > > > > > > > EDKII_CRYPTO_PROTOCOL is *private*. > > > > > > > > > > https://github.com/tianocore/edk2/blob/master/CryptoPkg/Private/Protocol= /C > > > > rypto.h > > > > > > > > Why we cannot change? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: devel@edk2.groups.io On Behalf Of > Siyuan, > > > Fu > > > > > Sent: Friday, March 27, 2020 10:47 AM > > > > > To: Gao, Zhichao ; devel@edk2.groups.io > > > > > Cc: Wang, Jian J ; Lu, XiaoyuX > > > > ; > > > > > Maciej Rabeda ; Wu, Jiaxin > > > > > > > > > > Subject: Re: [edk2-devel] [PATCH 0/8] CryptoPkg: Retire the depr= ecate > > > > function > > > > > > > > > > Hi, Zhichao > > > > > > > > > > We should never move/delete a member field of a previous defined > > protocol > > > > > Interface. Instead, these protocol APIs shall be kept and return= an error > > code > > > > > If the function is retired. Otherwise the consumer driver may ca= ll into an > > > > > Incorrect function if it's build with different codebase/PCD set= tings with > > the > > > > > Crypto PEI/DXE/SMM driver. > > > > > This comment applies to all the EDKII_CRYPTO_PROTOCOL related > changes > > > in > > > > > your patch set. > > > > > > > > > > Best Regards > > > > > Siyuan > > > > > > > > > > > -----Original Message----- > > > > > > From: Gao, Zhichao > > > > > > Sent: 2020=1B$BG/=1B(B3=1B$B7n=1B(B27=1B$BF|=1B(B 9:56 > > > > > > To: devel@edk2.groups.io > > > > > > Cc: Wang, Jian J ; Lu, XiaoyuX > > > > > ; > > > > > > Maciej Rabeda ; Wu, Jiaxin > > > > > > ; Fu, Siyuan > > > > > > Subject: [PATCH 0/8] CryptoPkg: Retire the deprecate function > > > > > > > > > > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1682 > > > > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1898 > > > > > > > > > > > > MD4, AR4, Tdes, Aes Ecb mode, MD5 and SHA1 is not secure any l= onger. > > > > > > They are all deprecated. Edk2 would not support them any longe= r. > > > > > > So remove them. > > > > > > But uefi spec want to keep MD5 and SHA1 for backwards compatib= ility. > > > > > > So add two pcds to control the MD5 and SHA1 enablement. Set th= e > pcds > > > > > > default value to false to indicate they are deprecated. > > > > > > > > > > > > NetWorkPkg's iSCSI driver would consume the MD5 function, so c= hange > > > > > > the md5 pcd to TURE when iSCSI is enabled. > > > > > > > > > > > > Cc: Jian J Wang > > > > > > Cc: Xiaoyu Lu > > > > > > Cc: Maciej Rabeda > > > > > > Cc: Jiaxin Wu > > > > > > Cc: Siyuan Fu > > > > > > Signed-off-by: Zhichao Gao > > > > > > > > > > > > Zhichao Gao (8): > > > > > > CryptoPkg/BaseCrpytLib: Retire MD4 algorithm > > > > > > CryptoPkg/BaseCryptLib: Retire ARC4 algorithm > > > > > > CryptoPkg/BaseCryptLib: Retire the Tdes algorithm > > > > > > CryptoPkg/BaseCryptLib: Retire Aes Ecb mode algorithm > > > > > > CryptoPkg/dec: Add pcds to avoid building the deprecated fun= ction > > > > > > NetWorkPkg/Pcd.inc: Enable the MD5 for iSCSI > > > > > > Crypto/BaseCryptLib: Using pcd to control MD5 enablement > > > > > > CryptoPkg/BaseCryptLib: Use Pcd to control the SHA1 enableme= nt > > > > > > > > > > > > CryptoPkg/CryptoPkg.dec | 11 + > > > > > > CryptoPkg/CryptoPkg.uni | 11 + > > > > > > CryptoPkg/Driver/Crypto.c | 634 +--------= --------- > > > > > > CryptoPkg/Include/Library/BaseCryptLib.h | 548 ---------= ------ > > > > > > .../Library/BaseCryptLib/BaseCryptLib.inf | 9 +- > > > > > > .../Library/BaseCryptLib/Cipher/CryptAes.c | 114 ---- > > > > > > .../BaseCryptLib/Cipher/CryptAesNull.c | 52 -- > > > > > > .../Library/BaseCryptLib/Cipher/CryptArc4.c | 205 ------ > > > > > > .../BaseCryptLib/Cipher/CryptArc4Null.c | 124 ---- > > > > > > .../Library/BaseCryptLib/Cipher/CryptTdes.c | 364 ---------= - > > > > > > .../BaseCryptLib/Cipher/CryptTdesNull.c | 160 ----- > > > > > > .../Library/BaseCryptLib/Hash/CryptMd4.c | 223 ------ > > > > > > .../Library/BaseCryptLib/Hash/CryptMd4Null.c | 143 ---- > > > > > > .../Library/BaseCryptLib/Hash/CryptMd5.c | 5 +- > > > > > > .../Library/BaseCryptLib/Hmac/CryptHmacMd5.c | 3 + > > > > > > .../BaseCryptLib/Hmac/CryptHmacMd5Null.c | 3 + > > > > > > .../Library/BaseCryptLib/Hmac/CryptHmacSha1.c | 3 + > > > > > > .../BaseCryptLib/Hmac/CryptHmacSha1Null.c | 3 + > > > > > > .../Library/BaseCryptLib/PeiCryptLib.inf | 13 +- > > > > > > .../BaseCryptLib/Pk/CryptPkcs5Pbkdf2.c | 3 + > > > > > > .../Library/BaseCryptLib/Pk/CryptRsaBasic.c | 5 + > > > > > > .../Library/BaseCryptLib/Pk/CryptRsaExt.c | 5 + > > > > > > .../Library/BaseCryptLib/RuntimeCryptLib.inf | 13 +- > > > > > > .../Library/BaseCryptLib/SmmCryptLib.inf | 13 +- > > > > > > .../BaseCryptLibNull/BaseCryptLibNull.inf | 3 - > > > > > > .../BaseCryptLibNull/Cipher/CryptAesNull.c | 54 +- > > > > > > .../BaseCryptLibNull/Cipher/CryptArc4Null.c | 124 ---- > > > > > > .../BaseCryptLibNull/Cipher/CryptTdesNull.c | 160 ----- > > > > > > .../BaseCryptLibNull/Hash/CryptMd4Null.c | 143 ---- > > > > > > .../BaseCryptLibNull/Hash/CryptMd5Null.c | 3 + > > > > > > .../BaseCryptLibNull/Hmac/CryptHmacMd5Null.c | 3 + > > > > > > .../BaseCryptLibNull/Hmac/CryptHmacSha1Null.c | 4 +- > > > > > > .../BaseCryptLibOnProtocolPpi/CryptLib.c | 604 +--------= -------- > > > > > > .../Library/BaseHashApiLib/BaseHashApiLib.c | 12 + > > > > > > .../Library/BaseHashApiLib/BaseHashApiLib.inf | 1 + > > > > > > CryptoPkg/Private/Protocol/Crypto.h | 583 +--------= ------- > > > > > > NetworkPkg/NetworkPcds.dsc.inc | 5 +- > > > > > > 37 files changed, 145 insertions(+), 4221 deletions(-) > > > > > > delete mode 100644 > > CryptoPkg/Library/BaseCryptLib/Cipher/CryptArc4.c > > > > > > delete mode 100644 > > > > CryptoPkg/Library/BaseCryptLib/Cipher/CryptArc4Null.c > > > > > > delete mode 100644 > > CryptoPkg/Library/BaseCryptLib/Cipher/CryptTdes.c > > > > > > delete mode 100644 > > > > CryptoPkg/Library/BaseCryptLib/Cipher/CryptTdesNull.c > > > > > > delete mode 100644 > CryptoPkg/Library/BaseCryptLib/Hash/CryptMd4.c > > > > > > delete mode 100644 > > > CryptoPkg/Library/BaseCryptLib/Hash/CryptMd4Null.c > > > > > > delete mode 100644 > > > > > > CryptoPkg/Library/BaseCryptLibNull/Cipher/CryptArc4Null.c > > > > > > delete mode 100644 > > > > > > CryptoPkg/Library/BaseCryptLibNull/Cipher/CryptTdesNull.c > > > > > > delete mode 100644 > > > > > CryptoPkg/Library/BaseCryptLibNull/Hash/CryptMd4Null.c > > > > > > > > > > > > -- > > > > > > 2.21.0.windows.1 > > > > > > > > > > > > > > >=20