Re: [edk2-devel] [RFC] Add parallel hash feature into CryptoPkg.BaseCryptLib.

["Ethin Probst" <harlydavidsen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 8267 bytes --]

I think another problem that we need to consider is that to my knowledge,
the MP services do not allow for thread scheduling at all. You can run a
call back on multiple processors, but that won't increase the performance
of the function you're calling because the function will be executed
independently of all other processors doing the work, so you would need to
intelligently write the function to determine what processor it's on and
that in turn would determine what work the function does. This would also
bring in the requirement for synchronization primitives like mutexes and
locks. I'm not sure how exactly that could be accomplished without changing
the API, or at least adding new functionality to it. But I may be missing
something and this may be possible. But last time I checked, UEFI did not
contain a thread-based scheduler.

On Thu, Sep 2, 2021, 20:02 Yao, Jiewen <jiewen.yao@intel.com> wrote:
>
> Hi
>
> 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?
>
>
>
> Thank you
>
> Yao Jiewen
>
>
>
> From: Andrew Fish <afish@apple.com>
> Sent: Friday, September 3, 2021 7:16 AM
> To: edk2-devel-groups-io <devel@edk2.groups.io>; Kinney, Michael D <
michael.d.kinney@intel.com>
> Cc: Li, Zhihao <zhihao.li@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>;
Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Lu,
XiaoyuX <xiaoyux.lu@intel.com>; Jiang, Guomin <guomin.jiang@intel.com>;
gaoliming@byosoft.com.cn; Fu, Siyuan <siyuan.fu@intel.com>; Wu, Yidong <
yidong.wu@intel.com>; Li, Aaron <aaron.li@intel.com>
> Subject: Re: [edk2-devel] [RFC] Add parallel hash feature into
CryptoPkg.BaseCryptLib.
>
>
>
>
>
>
>
>> On Sep 2, 2021, at 8:50 AM, Michael D Kinney <michael.d.kinney@intel.com>
wrote:
>>
>>
>>
>> Hi Zhihao,
>>
>>
>>
>> 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.
>>
>>
>
>
>
>
>
> 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 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.
>
>
>
>
>
> [1] We don’t have a Base implementation of BaseCryptLib.
>
> CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
>
> LIBRARY_CLASS                  = BaseCryptLib|DXE_DRIVER DXE_CORE
UEFI_APPLICATION UEFI_DRIVER
>
>
>
> CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
>
> LIBRARY_CLASS                  = BaseCryptLib|PEIM PEI_CORE
>
>
>
>  CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
>
> LIBRARY_CLASS                  = BaseCryptLib|DXE_RUNTIME_DRIVER
>
>
>
> CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
>
>   LIBRARY_CLASS                  = BaseCryptLib|DXE_SMM_DRIVER SMM_CORE
MM_STANDALONE
>
>
>
> [2]
https://github.com/tianocore/edk2/blob/master/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c#L77
>
>
>
> Thanks,
>
>
>
> Andrew Fish
>
>
>
>> Thanks,
>>
>>
>>
>> Mike
>>
>>
>>
>> From: devel@edk2.groups.io <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 <jiewen.yao@intel.com>; Wang, Jian J <
jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Lu, XiaoyuX <
xiaoyux.lu@intel.com>; Jiang, Guomin <guomin.jiang@intel.com>;
gaoliming@byosoft.com.cn; Fu, Siyuan <siyuan.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 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.
>>
>>
>>
>> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=3596
>>
>>
>>
>> [Background]
>>
>> 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.
>>
>>
>>
>> [Proposal]
>>
>> 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.
>>
>>
>>
>> [Required Changes]
>>
>> 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 in
BaseCryptLib?
>>
>> 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!
>>
>> Best regards,
>> Zhihao
>>
>>
>
>
>
> 

[-- Attachment #2: Type: text/html, Size: 11460 bytes --]