Createa a dedicated object create API for _TPM_HASH_START use case #12
+45
−3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It is observed that asymmetric handling for CryptHashStart() and CryptHashEnd2B() in _TPM_HASH_START() and _TPM_HASH_END(), where PcrIsAllocated() is applied in _TPM_HASH_END() but not in _TPM_HASH_START(). This causes the device hardware drip issue in FW TPM HW crypto engine support use case, meaning device can't go to sleep due to the HW crypto engine seeing some pending work.
To fix the above issue, a dedicated API ObjectCreateEventSequenceHcrtmDrtm() is created and called in _TPM_HASH_START() for HCRTM/DRTM cases. Inside this newly created API, PcrIsAllocated() is applied in handling CryptHashStart(), so that all hash contexts initialized in _TPM_HASH_START() will be de-initialized in _TPM_HASH_END().
This fix has been tested in FW TPM with HW crypto engine support use case, and the device sleep issue is gone after applying this fix.