Repository navigation
Conversation
|
Hi maintainers, a gentle ping on this PR. Could someone take a look when you have time? Please let me know if any changes or additional tests are needed. Thanks! |
|
If I remember correctly, the session must always use the hash alg defined as nameAlg for the object being accessed. So instead of getting this from a CLI parameter, it should be retrieved from the object being accessed. P.S. Sorry it took so long |
chench246
changed the title
Updated the PR to derive the implicit PCR policy session hash from the accessed object's nameAlg, as suggested. The proposed @ CLI syntax has been removed. The implementation now defers only pcr: authorization until the object ESYS handle is available, then uses the object's nameAlg when creating the implicit policy session. Other authorization forms remain unchanged, including an explicitly created policy session passed through session:. The GitHub Actions runs are currently waiting for approval. Could you please take another look? |
moritzbuhl
left a comment
moritzbuhl
left a comment
There was a problem hiding this comment.
I will look into this myself and get this in.
| tool_rc rc = tool_rc_success; | ||
| if (do_auth) { | ||
| bool defer_pcr_auth = do_auth && !is_restricted_pswd_session && auth && | ||
| !strncmp(auth, "pcr:", sizeof("pcr:") - 1); |
There was a problem hiding this comment.
PCR_PREFIX and PCR_PREFIX_LEN
| tool_rc tpm2_auth_util_from_optarg(ESYS_CONTEXT *ectx, const char *password, | ||
| tpm2_session **session, bool is_restricted) { | ||
|
|
||
| password = password ? password : ""; |
| const char *password, tpm2_session **session, bool is_restricted, | ||
| ESYS_TR auth_handle) { | ||
|
|
||
| password = password ? password : ""; |
| tpm2 flushcontext -Q -t | ||
|
|
||
| rm $file_unseal_key_pub $file_unseal_key_priv $file_unseal_key_name \ | ||
| $file_unseal_key_ctx |
There was a problem hiding this comment.
indentation is wrong here too.
Implicit PCR authorization created its policy session before the authorization object was loaded, so the session used the default hash algorithm. Authorization then failed when the object policy used a non-default nameAlg, although an explicit policy session with the matching hash worked. Defer only pcr: authorization until the object ESYS handle is available, then use the object nameAlg as the implicit policy session hash. Preserve the existing fallback for an invalid or non-hash nameAlg. Leave other authorization forms and explicitly created sessions unchanged. Add unit coverage for nameAlg selection and fallback behavior, plus swtpm integration coverage for implicit and explicit PCR authorization. Signed-off-by: chench246 <chench246@hotmail.com>
3 participants
Problem
Implicit
pcr:authorization creates its policy session before the authorized object is loaded. The session therefore uses the default hash algorithm and fails withTPM_RC_POLICY_FAILwhen the object policy uses a non-defaultnameAlg.Solution
Defer only implicit
pcr:authorization until the object ESYS handle is available, then use the objectnameAlgas the policy-session hash. Keep the existing fallback for invalid or non-hash name algorithms.Other authorization forms are unchanged, including explicitly created sessions passed through
session:.Tests
nameAlgselection and fallback behaviorstartauthsessionpath remains successfulpcr:sha256:...succeeds without a new CLI parameter