From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.apple.com [17.179.253.49]) by mx.groups.io with SMTP id smtpd.web10.1334.1630624616542108471 for ; Thu, 02 Sep 2021 16:16:56 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=mpqKhfhq; spf=pass (domain: apple.com, ip: 17.179.253.49, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 182NBYxq029440; Thu, 2 Sep 2021 16:16:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=/526wglhwsOkldTsOGXp9Wulxa/5Nk0wp3iqPd34A4o=; b=mpqKhfhq6QijE2be+32A1Tu988T9aSmpFtTWpJq3PpcW6hIkvPhXMyg8r+KFtUSsP4Cm hPEVvjV1M6+KGeCxD/CkzKh5rWp7WlJyCn9Ro2wWkRu0M//GwUTtYfz6RrSFa2yj2FG1 wlhKQAmRxzfFQIcP3Fc2gZbmrYpUcoLPtOyyr8MGgK8dgwAc/fbWyuJmbMppHnR2NraL BfbBUh17ga/b78ikmbjRckc80HLttPd+c08PCRWJupgNcwoH6vy5iV2XgAZDjDaqHe8g TVTIg3KXToTVSnHSefc9zZmM1m+GRUV/lx8YmB1XyGD8ige1FbNbmAS0XrA5dadxJ352 xg== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 3au6q2911h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 02 Sep 2021 16:16:42 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QYT00QCTXZUZGE0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Thu, 02 Sep 2021 16:16:42 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QYT00700XXC8C00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 02 Sep 2021 16:16:42 -0700 (PDT) X-Va-A: X-Va-T-CD: 70a38c3f5b1d46c4b8dccb3b011be358 X-Va-E-CD: 0e71faaa74deee27be6cc6435f198a27 X-Va-R-CD: 79667a3028e28a06a8cc60a58167086a X-Va-CD: 0 X-Va-ID: c3eef4ab-1f52-4534-8104-09f691ac13d5 X-V-A: X-V-T-CD: 70a38c3f5b1d46c4b8dccb3b011be358 X-V-E-CD: 0e71faaa74deee27be6cc6435f198a27 X-V-R-CD: 79667a3028e28a06a8cc60a58167086a X-V-CD: 0 X-V-ID: 1e060ce5-ab1d-40f7-a844-0f2047b47e13 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-09-02_04:2021-09-02,2021-09-02 signatures=0 Received: from [17.235.13.23] (unknown [17.235.13.23]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QYT00SACXZCA000@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 02 Sep 2021 16:16:25 -0700 (PDT) From: "Andrew Fish" Message-id: <12E67558-0528-4623-969C-02F3A2559B51@apple.com> MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib. Date: Thu, 02 Sep 2021 16:16:23 -0700 In-reply-to: Cc: "Li, Zhihao" , "Yao, Jiewen" , "Wang, Jian J" , "Wu, Hao A" , "Lu, XiaoyuX" , "Jiang, Guomin" , "gaoliming@byosoft.com.cn" , "Fu, Siyuan" , "Wu, Yidong" , "Li, Aaron" To: edk2-devel-groups-io , Mike Kinney References: X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-09-02_04:2021-09-02,2021-09-02 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_07200990-84B5-48B9-A7E8-A185B5A292FD" --Apple-Mail=_07200990-84B5-48B9-A7E8-A185B5A292FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 2, 2021, at 8:50 AM, Michael D Kinney = wrote: >=20 > Hi Zhihao, > =20 > Is the result of the parallel hash identical to the current hash? If so,= then can we simply have a new instance of the FmpAuthenticationLib and hid= e the ParallelHash256 digest inside this implementation of this new instanc= e? > =20 > I do not think BaseCryptLib should depend on CPU MP Services Protocol. C= an the use of MP Services be moved up into the implementation of the new Fm= pAuthenticationLib? If new BASE compatible primitives need to be added to = BaseCryptLib to support parallel hash, then those likely make sense. > =20 Mike, Stupid question but the BaseCryptLib seems to really be DxeCryptLib[1]? So = are you worried about adding the dependency to this DXE Lib? It depends on = UefiRuntimeServicesTableLib. Looks like SysCall/TimerWrapper.c[2] uses gRT-= >GetTime(). It looks like if the time services are not available it returns= 0 from time(), so there is only a quality of service implication to when i= t it is used but no Depex? > How do you decide how many CPU threads to use?=20 > =20 If we end up splitting this up for =E2=80=9Cothers=E2=80=9D to handle the M= P in DXE, PEI, or MM then I think we probably need a more robust API set th= at abstracts breaking up the work, and combining it back tougher. Well you = would need the worker functions to processes the broken up data on the APs.= So I would imagine and API that splits the work and you pass in the number= of APs (or APs + BSP) and you get N buffers out to process? Those buffers = should describe the chunk to the worker function, and when the worker funct= ion is done the get the answer function can calculate the results from that= .=20 [1] We don=E2=80=99t have a Base implementation of BaseCryptLib.=20 CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf LIBRARY_CLASS =3D BaseCryptLib|DXE_DRIVER DXE_CORE UEFI_AP= PLICATION UEFI_DRIVER CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf LIBRARY_CLASS =3D BaseCryptLib|PEIM PEI_CORE CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf LIBRARY_CLASS =3D BaseCryptLib|DXE_RUNTIME_DRIVER CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf LIBRARY_CLASS =3D BaseCryptLib|DXE_SMM_DRIVER SMM_CORE M= M_STANDALONE [2] https://github.com/tianocore/edk2/blob/master/CryptoPkg/Library/BaseCry= ptLib/SysCall/TimerWrapper.c#L77 Thanks, Andrew Fish > Thanks, > =20 > Mike > =20 > From: devel@edk2.groups.io > On Behalf Of Li, Zhihao > Sent: Wednesday, September 1, 2021 6:38 PM > To: devel@edk2.groups.io > Cc: Yao, Jiewen >; Wan= g, Jian J >; Wu, Hao A= >; Lu, XiaoyuX >; Jiang, Guomin >; gaoliming@byosoft.com.cn ; Fu, Siyuan >; Wu, Yidong >; = Li, Aaron > > Subject: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.Base= CryptLib > =20 > Hi, everyone. > We want to add new hash algorithm=E2=80=94cSHAKE256/ParallelHash256 defin= ed by NIST SP 800-185=E2=80=94into BaseCryptLib of CryptoPkg. This feature = can be applied for digital authentication functions like Capsule Update. It= utilizes multi-processor to calculate the image digest in parallel for upd= ate capsule authentication so that lessen the time of capsule authenticatio= n. > =20 > Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3596 > =20 > [Background] > The intention of this change is to improve the capsule authentication per= formance. > Currently, the image is calculated to a hash value (usually by SHA-256), = then the hash value be signed by a certificate. The header, certificate, an= d image binary be sealed to the capsule. In authentication phase, the progr= am should calculate the hash using image binary in capsule and then perform= authentication procedures. > =20 > [Proposal] > Now, we propose a new authentication flow, which firstly pre-calculates t= he ParallelHash256 digest of the image binary in parallel with multi-proces= sors, then use the ParallelHash256 digest (instead of original image binary= ) in subsequent SHA-256 hash for sign/authentication. > Since the big size image be compressed to the ParallelHash256 digest that= only have 256 bytes, the time of SHA-256 running would be less. > =20 > [Required Changes] > Mainly in CryptoPkg, MdeModulePkg, SecurityPkg: > 1. CryptoPkg: need to add the new hash algorithm named cSHAKE256/Parallel= Hash256 in BaseCrypLib. The ParallelHash function will consume CPU MP Servi= ce Protocol, not sure if this is allowed in BaseCryptLib? > 2. MdeMoudulePkg: Add new authenticate function AuthenticateFmpImageWithP= arallelhash() to FmpAuthenticationLib. This is because original Authenticat= eFmpImage() interface only have 4 parameters while the new have 5 paramete= rs. The 5th parameter is ParallelHash256 digest raised above. We try to do = the parallel hash before authentication and transfer the result to Authenti= cateFmpImage function as parameter. So that we can do only once parallel ha= sh externally in the case of multiple authentication which saves more time. > 3. SecurityPkg: Add new function named FmpAuthenticatedHandlerPkcs7WithPa= rallelhash() and AuthenticateFmpImageWithParallelhash() to FmpAuthenticatio= nLibPkcs7. This is because original interfaces not have the formal paramete= r (ParallelHash256 digest) we need. We try to do the parallel hash before a= uthentication and transfer the result to AuthenticateFmpImage and FmpAuthen= ticatedHandlerPkcs7 function as parameter. So that we can do only once para= llel hash externally in the case of multiple authentication which saves mor= e time. > =20 > Please let me know if you have any comment or concern on this proposed ch= ange. > =20 > Thanks for your time and feedback! >=20 > Best regards, > Zhihao > =20 >=20 --Apple-Mail=_07200990-84B5-48B9-A7E8-A185B5A292FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 2, 202= 1, at 8:50 AM, Michael D Kinney <michael.d.kinney@intel.com> wrote:

Hi Zhi= hao,
 
Is the result of the parallel hash identical to th= e current hash?  If so, then can we simply have a new instance of the Fmp= AuthenticationLib = and hide the ParallelHash256 digest inside this implementation of= this new instance?
 
I do not think BaseCryptLib should depend on CPU MP Services P= rotocol.  = Can the use of MP Services be moved up into the implementatio= n of the new FmpAuthenticationLib?  If new BASE compatible primi= tives need to be added to BaseCryptLib to support parallel hash, then those likely make sense.<= o:p class=3D"">
 


Mike,

Stupid question but the BaseCryptLib seems to really = be DxeCryptLib[1]? So are you worried about adding the dependency to this D= XE Lib? It depends on UefiRuntimeServicesTableLib. Looks like Sys= Call/TimerWrapper.c[2] uses gRT->GetTime(). It looks like if the time se= rvices are not available it returns 0 from time(), so there is only a quali= ty of service implication to when it it is used but no Depex?

How do you d= ecide how many CPU threads to use? 
&n= bsp;

<= div>If we end up splitting this up for =E2=80=9Cothers=E2=80=9D to handle t= he MP in DXE, PEI, or MM then I think we probably need a more robust API se= t that abstracts breaking up the work, and combining it back tougher. Well = you would need the worker functions to processes the broken up data on the = APs. So I would imagine and API that splits the work and you pass in the nu= mber of APs (or APs + BSP) and you get N buffers out to process? Those buff= ers should describe the chunk to the worker function, and when the worker f= unction is done the get the answer function can calculate the results from = that. 


<= div>
[1] We don=E2=80=99t have a Base implementation of BaseCryptLib.&n= bsp;
CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
LIBRARY_CLASS =3D BaseCrypt= Lib|DXE_DRIVER DXE_CORE UEFI_APPLICATION UEFI_DRIVER

CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
LIBRARY_CLASS =3D Base= CryptLib|PEIM PEI_CORE

 Cry= ptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
LIBRARY_CLASS =3D BaseCryptLib|DXE_RUNTIME_DRI= VER

CryptoPkg/Librar= y/BaseCryptLib/SmmCryptLib.inf
LIBRARY_CLASS =3D BaseCryptLib|DXE= _SMM_DRIVER SMM_CORE MM_STANDALONE


<= /span>
Thanks,
=
Andr= ew Fish

Thanks,
 
<= span class=3D"">Mike
 
<= b class=3D"">From: devel@edk2.groups.io <= /span><devel@edk2.groups.io&= gt; On Beha= lf Of Li, Zhihao
Sent:&nbs= p;Wednesday, September 1, 2021 6:38 PM
T= o: devel@edk2.groups.io
= Cc: Yao, Jiewen <<= a href=3D"mailto:jiewen.yao@intel.com" style=3D"color: rgb(149, 79, 114); t= ext-decoration: underline;" class=3D"">jiewen.yao@intel.com>; Wang, = Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.= com>; Lu, XiaoyuX <xiaoy= ux.lu@intel.com>; Jiang, Guomin <guomin.jiang@intel.com>; gaoliming@byos= oft.com.cn; Fu, Siyuan <siyua= n.fu@intel.com>; Wu, Yidong <yidong.wu@intel.com>; Li, Aaron <aaron.li@intel.com>
Subject: [edk2-devel] [RFC] Add = parallel hash feature into CryptoPkg.BaseCryptLib
 
Hi, everyone.
We want to add new hash algorit= hm=E2=80=94cSHAKE256/ParallelHash256 defined by NIST SP 800-185=E2=80=94int= o BaseCryptLib of CryptoPkg. This feature can be applied for digital authen= tication functions like Capsule Update. It utilizes multi-processor to calc= ulate the image digest in parallel for update capsule authentication so tha= t lessen the time of capsule authentication.
 
Bugz= illa: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3596<= /a>
[Background]=
T= he intention of this change is to improve the capsule authentication perfor= mance.
Currently, the image is calculated to a h= ash value (usually by SHA-256), then the hash value be signed by a certific= ate. The header, certificate, and image binary be sealed to the capsule. In= authentication phase, the program should calculate the hash using image bi= nary in capsule and then perform authentication procedures.
=  
[Proposal]
Now, we propose a new auth= entication flow, which firstly pre-calculates the ParallelHash256 digest of= the image binary in parallel with multi-processors, then use the ParallelH= ash256 digest (instead of original image binary) in subsequent SHA-256 hash= for sign/authentication.
Since the big size ima= ge be compressed to the ParallelHash256 digest that only have 256 bytes, th= e time of SHA-256 running would be less.
=
 
<= div style=3D"margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif= ; background-color: white;" class=3D"">[Require= d Changes]
2. MdeMoudulePkg: Add new aut= henticate function AuthenticateFmpImageWithParallelhash() to FmpAuthenticat= ionLib. This is because original AuthenticateFmpImage() interface only have= 4 parameters  while the new have 5 parameters. The 5t= h parameter is Para= llelHash256 digest raised above. We try to do the parallel hash before auth= entication and transfer the result to AuthenticateFmpImage function as para= meter. So that we can do only once parallel hash externally in the case of = multiple authentication which saves more time.=
3= . SecurityPkg: Add new function named FmpAuthenticatedHandlerPkcs7WithParal= lelhash() and AuthenticateFmpImageWithParallelhash() to FmpAuthenticationLi= bPkcs7. This is because original interfaces not have the formal parameter (ParallelHash256 digest) we need. We try to do the parallel hash before authent= ication and transfer the result to AuthenticateFmpImage and FmpAuthenticate= dHandlerPkcs7 function as parameter. So that we can do only once parallel h= ash externally in the case of multiple authentication which saves more time= .
 
= Please let me know if you have any comment or c= oncern on this proposed change.
 
Thanks for your time and feedback!

Best regards,
Zhihao
 


--Apple-Mail=_07200990-84B5-48B9-A7E8-A185B5A292FD--