Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove ProvisionStatus and refactor provision API #104

Merged

Conversation

chrisccoulson
Copy link
Collaborator

ProvisionStatus is a problematic API - AttrValidSRK and AttrValidEK
indicate that objects with the expected public areas exist at the expected
handles, but can't indicate whether those objects were created with the
correct templates and are actually valid objects. These attributes can't
be used to make a decision about whether ProvisionTPM should be called or
not, so just remove the ProvisionStatus API entirely.

Rename ProvisionTPM to EnsureProvisioned (and make it a method of
TPMConnection), and introduce a new error (ErrTPMProvisioningRequiresLockout)
which is returned from EnsureProvisioned if it is called with
ProvisionModeWithoutLockout but use of the lockout hierarchy is required
to fully provision the TPM. This new error is an indication that
EnsureProvisioned needs to be called again with a different mode in order
to fully provision it.

ProvisionStatus is a problematic API - AttrValidSRK and AttrValidEK
indicate that objects with the expected public areas exist at the expected
handles, but can't indicate whether those objects were created with the
correct templates and are actually valid objects. These attributes can't
be used to make a decision about whether ProvisionTPM should be called or
not, so just remove the ProvisionStatus API entirely.

Rename ProvisionTPM to EnsureProvisioned (and make it a method of
TPMConnection), and introduce a new error (ErrTPMProvisioningRequiresLockout)
which is returned from EnsureProvisioned if it is called with
ProvisionModeWithoutLockout but use of the lockout hierarchy is required
to fully provision the TPM. This new error is an indication that
EnsureProvisioned needs to be called again with a different mode in order
to fully provision it.
@chrisccoulson chrisccoulson linked an issue Sep 11, 2020 that may be closed by this pull request
@chrisccoulson chrisccoulson added this to the uc20-final milestone Sep 22, 2020
@pedronis pedronis self-requested a review September 23, 2020 09:25
Copy link
Collaborator

@pedronis pedronis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, couple small comments

t.Fatalf("EnsureProvisioned failed: %v", err)
}

srk, err = tpm.CreateResourceContextFromTPM(tcg.SRKHandle)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is an additional test now?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is - it verifies that the TPM hasn't been cleared by making sure that the new primary key is identical to the original one.

@@ -321,7 +321,7 @@ func unsealKeyFromTPM(tpm *TPMConnection, k *SealedKeyObject, pin string) ([]byt
// has a null authorization value, then this will allow us to unseal the key without requiring any type of manual recovery. If the
// storage hierarchy has a non-null authorization value, ProvionTPM will fail. If the TPM owner has changed, ProvisionTPM might
// succeed, but UnsealFromTPM will fail with InvalidKeyFileError when retried.
if pErr := ProvisionTPM(tpm, ProvisionModeWithoutLockout, nil); pErr == nil {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the comment should maybe be expanded to cover the new || condition

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've actually changed this in #112 to just ignore the error instead, as there's not really any harm in attempting to unseal again even if provisioning fails with an error.

@chrisccoulson chrisccoulson merged commit 111df58 into canonical:master Sep 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove internal use of ProvisionStatus
2 participants