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

tpm2: Use tpm2.TPMDevice abstraction #357

Merged
merged 3 commits into from
Jan 8, 2025

Conversation

chrisccoulson
Copy link
Collaborator

Secboot currently opens a transport to the Linux character device at a hardcoded path (/dev/tpm0) and passes the opened transport to the deprecated tpm2.NewTPMContext API. The replacement API (tpm2.OpenTPMDevice) makes use of a new abstraction (tpm2.TPMDevice).

The linux sub-package provides a way of enumerating TPM devices or providing access to the default one. It also provides access to the resource managed device, which we might want to use in secboot in the future, and it provides access to the physical presence interface for performing actions that are implemented in platform firmware.

Implementing this now is required to write test cases for #353, as the current test harness will permit the code under test to open as many TPM connections as it likes, when in reality, it can only have a single open connection if it is using the direct character device (/dev/tpm0).

@chrisccoulson chrisccoulson force-pushed the tpm2-use-tpm-device branch 3 times, most recently from 52a2864 to 382a512 Compare January 7, 2025 22:21
Secboot currently opens a transport to the Linux character device at a
hardcoded path (/dev/tpm0) and passes the opened transport to the
deprecated tpm2.NewTPMContext API. The replacement API
(tpm2.OpenTPMDevice) makes use of a new abstraction (tpm2.TPMDevice).

The linux sub-package provides a way of enumerating TPM devices or
providing access to the default one. It also provides access to the
resource managed device, which we might want to use in secboot in the
future, and it provides access to the physical presence interface for
performing actions that are implemented in platform firmware.

Implementing this now is required to write test cases for
canonical#353, as the current test
harness will permit the code under test to open as many TPM connections
as it likes, when in reality, it can only have a single open connection
if it is using the direct character device (/dev/tpm0).
@chrisccoulson chrisccoulson requested a review from pedronis January 8, 2025 09:48
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.

thank you

@chrisccoulson chrisccoulson merged commit 31629d7 into canonical:master Jan 8, 2025
2 checks passed
chrisccoulson added a commit to chrisccoulson/secboot that referenced this pull request Jan 16, 2025
PR canonical#357 migrated the tpm2 code to using the new tpm2.TPMDevice
abstraction for opening TPM connections.

The go-tpm2 package contains some other deprecated APIs, and in some
cases, entire packages have been deprecated (crypto, templates, util).
These have been replaced by alternative APIs, and ithe util package,
which was a bit of a dumping ground for APIs that had nowhere else to
go, has been split into more focused packages.

This ports secboot to using updated APIs. It's just a straight port for
now - we may want to refactor some code to make better use of these APIs
in future PRs.
chrisccoulson added a commit that referenced this pull request Jan 17, 2025
…-go-tpm2-apis

tpm2: Stop using deprecated go-tpm2 APIs.

PR #357 migrated the tpm2 code to using the new tpm2.TPMDevice abstraction for opening TPM connections.

The go-tpm2 package contains some other deprecated APIs, and in some cases, entire sub-packages have been deprecated (crypto, templates, util). These have been replaced by alternative APIs, and the util package, which was a bit of a dumping ground for APIs that had nowhere else to go, has been split into more focused packages.

This ports secboot to using updated APIs. It's just a straight port for now - we may want to refactor some code to make better use of these APIs in future PRs - particularly those in the `policyutil` sub-package, something that will allow us to create keys with arbitrary policies without having to change the key data format for tpm2 keys (see issue #350).
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.

2 participants