toggle quoted messageShow quoted text
Comment on 2/3.
I am not sure if the a new function AuthenticateFmpImageWithParallelhash() is absolutely necessary.
Why you do the parallel hash before authentication and transfer the result to AuthenticateFmpImage?
Why we cannot do it inside of AuthenticateFmpImage?
Ideally, we hope to hide *algorithm* from *business logic*.
Do you have any POC link?
Andrew Fish <afish@...>
Friday, September 3, 2021 7:16 AM
edk2-devel-groups-io <firstname.lastname@example.org>; Kinney, Michael D <michael.d.kinney@...>
Li, Zhihao <zhihao.li@...>; Yao, Jiewen <jiewen.yao@...>; Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>; gaoliming@...; Fu,
Siyuan <siyuan.fu@...>; Wu, Yidong <yidong.wu@...>; Li, Aaron <aaron.li@...>
Re: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib.
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
hide the ParallelHash256 digest inside this implementation of this new instance?
I do not think BaseCryptLib should depend on CPU MP Services Protocol. Can the
use of MP Services be moved up into the implementation of the new FmpAuthenticationLib? If new BASE compatible primitives need to be added to BaseCryptLib to
support parallel hash, then those likely make sense.
Stupid question but the BaseCryptLib seems to really be DxeCryptLib? So are you worried about adding the dependency to this DXE Lib? It depends on UefiRuntimeServicesTableLib. Looks like SysCall/TimerWrapper.c 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 it it is used but no Depex?
How do you decide how many CPU threads to use?
If we end up splitting this up for “others” to handle the MP in DXE, PEI, or MM then I think we probably need a more robust API set 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 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 function is done the get the answer function can calculate the results from that.
 We don’t have a Base implementation of BaseCryptLib.
LIBRARY_CLASS = BaseCryptLib|DXE_DRIVER DXE_CORE UEFI_APPLICATION UEFI_DRIVER
LIBRARY_CLASS = BaseCryptLib|PEIM PEI_CORE
LIBRARY_CLASS = BaseCryptLib|DXE_RUNTIME_DRIVER
LIBRARY_CLASS = BaseCryptLib|DXE_SMM_DRIVER SMM_CORE MM_STANDALONE
From: email@example.com <firstname.lastname@example.org> On
Behalf Of Li, Zhihao
Sent: Wednesday, September 1, 2021 6:38 PM
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J <jian.j.wang@...>;
Wu, Hao A <hao.a.wu@...>; Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>; gaoliming@...;
Fu, Siyuan <siyuan.fu@...>; Wu, Yidong <yidong.wu@...>; Li, Aaron <aaron.li@...>
Subject: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib
We want to add new hash algorithm—cSHAKE256/ParallelHash256 defined by NIST SP 800-185—into 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 update capsule authentication so that lessen the time of capsule authentication.
The intention of this change is to improve the capsule authentication performance.
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, and image binary be sealed to the capsule.
In authentication phase, the program should calculate the hash using image binary in capsule and then perform authentication procedures.
Now, we propose a new authentication flow, which firstly pre-calculates the ParallelHash256 digest of the image binary in parallel with multi-processors, 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.
Mainly in CryptoPkg, MdeModulePkg, SecurityPkg:
1. CryptoPkg: need to add the new hash algorithm named cSHAKE256/ParallelHash256 in BaseCrypLib. The ParallelHash function will consume CPU MP Service Protocol, not sure if this is allowed
2. MdeMoudulePkg: Add new authenticate function AuthenticateFmpImageWithParallelhash() to FmpAuthenticationLib. This is because original AuthenticateFmpImage() interface only have 4 parameters
while the new have 5 parameters. The 5th parameter is ParallelHash256 digest raised above. We try to do the parallel hash before authentication and transfer the result to AuthenticateFmpImage function as
parameter. 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 FmpAuthenticatedHandlerPkcs7WithParallelhash() and AuthenticateFmpImageWithParallelhash() to FmpAuthenticationLibPkcs7. This is because original interfaces
not have the formal parameter (ParallelHash256 digest)
we need. We try to do the parallel hash before authentication and transfer the result to AuthenticateFmpImage and FmpAuthenticatedHandlerPkcs7 function as parameter. So that we can
do only once parallel hash externally in the case of multiple authentication which saves more time.
Please let me know if you have any comment or concern on this proposed change.
Thanks for your time and feedback!