-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf
Of Nate DeSimone
Sent: Wednesday, November 20, 2019 10:31 PM
To: rfc@edk2.groups.io; Sukerkar, Amol N
<amol.n.sukerkar@...>
Cc: Agrawal, Sachin <sachin.agrawal@...>; Wang,
Jian J <jian.j.wang@...>
Subject: Re: [edk2-rfc] Unified API for Hashing
Algorithms in EDK2

Hi Amol,

With regard to verifying code hashes, it makes much
more sense to me to have a GUID defined that represents
the hash function to use versus a PCD. The reason for
this is the method for signing Firmware Volumes
typically involves using nested FVs where the GUID for
the nested FV type indicates the algorithm needed to
"extract" the nested FV. Extraction in this context is
used to verify code hashes as well as decompress
compressed code. The "extractor" is usually a
statically linked library attached to either
SignedSectionExtractPei and/or DxeIpl.

For example, it is very possible for a platform to use
more than one hashing algorithm, I can think of more
than one closed source platform at Intel that actually
does this.

Now, one thing that I think your document implies is
that we should have better APIs for crypto operations
in general. If that was the intent then I totally agree
with you. There are several reasons that I think this
should be done. First, the API for OpenSSL has a
tendency to change often enough to make integrating new
versions into older codebases a headache, putting an
abstraction layer on it would be helpful. Second, the
method used to consume OpenSSL in edk2 causes some
technical issues. Specifically, OpenSSL is statically
linked and it defines a crazy number of global
variables, enough so that on a debug build I have
noticed roughly a 20KB increase in binary size even if
you don't call a single function in OpenSSL. Wrapping
the crypto operations in a PPI/Protocol so that only 1
driver needs to link to OpenSSL would probably help
reduce binary size for most implementations. Your
current document does not define a PPI/Protocol, that
is something I would recommend.

One issue that prior attempts of wrapping OpenSSL in a
PPI/Protocol have run into is that all the crypto
functions need to be linked, even the ones that a
platform does not use, which results in a net negative
binary size impact. Accordingly, one would likely need
to break the crypto functionality into multiple
PPIs/Protocols so that only the functions a platform
needs are actually included. I think some experiments
need to be done to figure out the most optimal division
of crypto APIs.

Hope that helps,
Nate

-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf
Of Sukerkar, Amol N
Sent: Wednesday, November 20, 2019 8:28 AM
To: rfc@edk2.groups.io
Cc: Agrawal, Sachin <sachin.agrawal@...>; Wang,
Jian J <jian.j.wang@...>; Sukerkar, Amol N
<amol.n.sukerkar@...>; Sukerkar, Amol N
<amol.n.sukerkar@...>
Subject: [edk2-rfc] Unified API for Hashing Algorithms
in EDK2
Importance: High

Hello,

Currently the UEFI drivers using the SHA/SM3 hashing
algorithms use hard-coded API to calculate the hash,
such as, sha_256(...), etc. Since SHA384 and/or SM3 are
being increasingly adopted, it becomes cumbersome to
modify the driver with SHA384 or SM3 calls for each
application.

To better achieve this, we are proposing a unified API
which can be used by UEFI drivers that provides the
drivers with flexibility to use the hashing algorithm
they desired or the strongest hashing algorithm the
system supports (with openssl). Attached is the design
proposal for the same and we request feedback from the
community before we begin the process of making the
changes to EDK2 repo.

Alternatively, the design document is also attached to
Bugzilla,
https://bugzilla.tianocore.org/show_bug.cgi?id=2151.
You can also provide the feedback in the Bugzilla.

Thanks,
Amol