Create individual packages for Windows and Linux TPM transport #369
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
google#364 called to attention some long-standing technical debt around TPM transport. In particular, the stack looks like: (Linux or Windows) `OpenTPM` function calls the legacy `OpenTPM` function calls the tpmutil `OpenTPM` function At the bottom of the stack, tpmutil does some runtime introspection to see what type of TPM it wants to open (e.g., on Linux, the device could be either a device file or a socket). This runtime support is convenient, but also breaks dead-code elimination (for example, tinygo will fail to compile the UDS support code, and users have no way of leaving that out without patches). In principle, we've found within Google that "open my TPM" should be as un-smart as possible, to avoid awkward edge cases (for example, what happens if the logic finds two different TPMs on the system; which should it prefer; should it invisibly succeed and surprise the user?). Instead, the preferred pattern is to require the user to explicitly say which TPM they are trying to open. This change introduces 3 packages as a replacement for `transport.OpenTPM` (which this change marks as now Deprecated): `transport/linuxtpm.Open(path)` opens Linux device TPMs (e.g., /dev/tpm0 or /dev/tpmrm0) `transport/linuxudstpm.Open(path)` opens Linux Unix Domain Socket TPMs `transport/windowstpm.Open()` opens the TPM from TBS.dll Intentionally, the now-deprecated `transport.OpenTPM` is not touched. This would create an import cycle.
042968f to
23aabd5
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#364 called to attention some long-standing technical debt around TPM transport. In particular, the stack looks like:
(Linux or Windows)
OpenTPMfunctioncalls the legacy
OpenTPMfunctioncalls the tpmutil
OpenTPMfunctionAt the bottom of the stack, tpmutil does some runtime introspection to see what type of TPM it wants to open (e.g., on Linux, the device could be either a device file or a socket). This runtime support is convenient, but also breaks dead-code elimination (for example, tinygo will fail to compile the UDS support code, and users have no way of leaving that out without patches).
In principle, we've found within Google that "open my TPM" should be as un-smart as possible, to avoid awkward edge cases (for example, what happens if the logic finds two different TPMs on the system; which should it prefer; should it invisibly succeed and surprise the user?). Instead, the preferred pattern is to require the user to explicitly say which TPM they are trying to open.
This change introduces 3 packages as a replacement for
transport.OpenTPM(which this change marks as now Deprecated):transport/linuxtpm.Open(path)opens Linux device TPMs (e.g., /dev/tpm0 or /dev/tpmrm0)transport/windowstpm.Open()opens the TPM from TBS.dllI reverted the proposed
transport/linuxudstpm.Open()because upon testing it against IBM's swtpm project (very helpful notes: https://ejaaskel.dev/yocto-emulation-setting-up-qemu-with-tpm/), I got the following errors which imply that the UDS protocol is not simply "send TPM commands the same as you would to the device file":Test failure:
Simulator logs:
The legacy
transport.OpenTPMfunction failed with the same issue.Intentionally, the now-deprecated
transport.OpenTPMis not touched. This would create an import cycle.TESTED:
windowstpm.Openon a Windows system with a TPM.linuxtpm.Openwith both /dev/tpm0 and /dev/tpmrm0 on a Linux system with a TPMlinuxudstpm.Openwith the IBM simulator running with