tpm2-software
tpm2_createpolicy keeps dangling loaded session
When tpm2_createpolicy is called with --policy-pcr, it requires an output file (policy) being specified, but at the same time it creates and keeps a loaded session of type TPM2_SE_TRIAL.
Reproduction:
#> export TPM2TOOLS_TCTI=device:/dev/tpm0
#> tpm2_createpolicy --policy-pcr -l sha256:10 -L pcr.policy
372defeded4318e0ebc658590e25e0c7c9871bf037881739d39e14e4934151f3
#> tpm2_getcap handles-loaded-session
- 0x3000000
When called multiple times, the call fails on:
WARNING:esys:src/tss2-esys/api/Esys_StartAuthSession.c:390:Esys_StartAuthSession_Finish() Received TPM Error
ERROR:esys:src/tss2-esys/api/Esys_StartAuthSession.c:136:Esys_StartAuthSession() Esys Finish ErrorCode (0x00000903)
ERROR: Esys_StartAuthSession(0x903) - tpm:warn(2.0): out of memory for session contexts
ERROR: Unable to run tpm2_createpolicy
Is this intentional? Is it required to call tpm2_flushcontext -l every time the tpm2_createpolicy is called on raw TPM device or on software-emulated TPM (swtpm)? This does not happen on /dev/tpmrm0, though (as expected).
yes tpm2_flushcontext is needed here. Autoflush (-R) is only implemented for key objects.
I found one strange behaviour. Compare the following:
WARNING:esys:src/tss2-esys/api/Esys_StartAuthSession.c:390:Esys_StartAuthSession_Finish() Received TPM Error
ERROR:esys:src/tss2-esys/api/Esys_StartAuthSession.c:136:Esys_StartAuthSession() Esys Finish ErrorCode (0x00000903)
ERROR: Esys_StartAuthSession(0x903) - tpm:warn(2.0): out of memory for session contexts
ERROR: Unable to run tpm2_create
This happens in the clevis tool, which calls both tpm2_createpolicy and tpm2_create. The difference is that tpm2_createpolicy keeps dangling loaded session, while the tpm2_create does not. I would expect that tpm2_createpolicy also cleans the session after usage like the tpm2_create does. Right?
@oldium yes you are right it makes no sense keep the session which is just used to compute the policy digest. I will create a PR which flushes the session in this case. And I think also an option to save the session context should be added if --policy-session is used.