attestation/tpm2 performance: don't check tpm readiness for attestation preparedness |
|||||||||
Issue descriptionThe first thing IsPreparedForAttestation currently does is checking if tpm is ready. Only then it checks the attestation database status. That optimization leads to the opposite effects - checking the tpm status leads to a trip to tpm_managerd, which can bock there waiting for a long tpm operation. 1) Avoid, if possible, checking the tpm readiness status in IsPreparedForAttestation - rely on the database state. [Needs to be confirmed that it will not lead to wrong results in corner cases.] 2) Cache, if possible, the tpm readiness status and request only when change is possible (see also issue 777679).
,
Jan 13 2018
,
Oct 12
,
Oct 17
,
Nov 2
,
Nov 21
I'll give it a try.
,
Nov 28
,
Nov 28
,
Nov 28
cl uploaded at crrev/c/1352015
,
Nov 28
Just a note, I've considered about changing the behavior of AttestationService::GetStatusTask() (which calls IsPreparedForEnrollment()) so that the prepared_for_enrollment variable of that API remains the same to the outside. However, I did not do so, because I've searched around for users of our APIs, and the existing ones aren't affected by this change. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by apronin@chromium.org
, Oct 24 2017