-
Notifications
You must be signed in to change notification settings - Fork 352
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
TCTI state transitions are inconsistent and unpredictable #2674
Labels
Comments
I am currently experiencing issues running latest tpm2-tss with the ibmswtpm2. Could this bug be the reason and what is a good tpm2 tss version that has mssim TCTI stable?
|
With |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Looking through the TCTI code, I have noticed a couple of inconsistencies.
Cancellation
The
tcti-mssim
andtcti-pcap
TCTIs will transition directly to theTCTI_STATE_TRANSMIT
state after a successful call tocancel
. This contradicts the specification which states that another call toreceive
is required before another command can be transmitted. This means there's no way for the caller to get the response buffer for the cancelled command, which is required to tell if the command actually executed or not. Higher layers in the stack will likely also hit unexpected errors if a command using these TCTIs is cancelled. For example, I think the ESYS library will enter an unrecoverable internal error state if the caller doeswhich I believe is the intended pattern for cancelling a command. Note that skipping the
Esys_{Command}_Finish
call leaves the ESYS context in the_ESYS_STATE_SENT
state where new commands cannot be issued, which is effectively the same as the unrecoverable error state for this purpose.All other TCTIs in this repo appear to act correctly in this regard. This looks like it's straight forward to fix, but I don't know much about the lower level interface they're using. Given the above, I would guess no one is relying on this behaviour.
Receive errors
Some TCTIs will also transition to the
TCTI_STATE_TRANSMIT
state on certain errors in thereceive
call. The spec doesn't explicitly comment on this either way, and neither do the man pages or installed headers, but there is a comment in internaltcti-common.h
header that claims this occurs for all return codes other thanTRY_AGAIN
,INSUFFICIENT_BUFFER
,BAD_CONTEXT
,BAD_REFERENCE
,BAD_VALUE
, andBAD_SEQUENCE
, but the behaviour of some TCTIs diverges from this. For example:tcti-cmd
transitions when returningINSUFFICIENT_BUFFER
.tcti-device
does not transition when returningIO_ERROR
. It is also ambiguous when returning unmarshaling errors andGENERAL_FAILURE
, transitioning on some code paths but not others.tcti-i2c-helper
only transitions when returningSUCCESS
, even though there are paths that returnIO_ERROR
and lower-layer errors that don't document any restrictions on the errors they should return.tcti-pcap
doesn't appear to interpret error codes from the underlying TCTI to decide whether to change its own state or not, if these get out of sync the TCTI would become unusable.tcti-libtpms
andtcti-mssim
appear to behave correctly i.e. the same as the comment intcti-common.h
.This has very similar issues as the cancellation issue, where higher layers of the stack are entirely unprepared for this.
My theory of the intent of this behaviour is that it's intended to represent three types of errors through different error codes:
receive
.Considering the widely varying existing behaviour, and the common pattern of returning error codes from lower layers without inspection, I think trying to signal the presence or absence of a state transition through the specific error code returned was a mistake.
The most straightforward fix within the existing interface would be to say that error returns never indicate a transition out of the
TCTI_STATE_RECEIVE
state. Equivalently,transmit
can only be called after initialization or a successfulreceive
call. Transient errors then get retried by the caller as appropriate, and a fatal error is represented by simply never being able to perform a successfulreceive
. Higher layers of software generally seem to assume this already, but it's more likely that someone would be broken by this than by the proposed cancellation fix above.The text was updated successfully, but these errors were encountered: