microsoft/mu_feature_ffa
Publicmirrored from https://github.com/microsoft/mu_feature_ffaAvailable
FfaFeaturePkg/Docs/TpmService.md
82lines · modecode
| 1 | # TPM Service |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | The TPM service found in FfaFeaturePkg/Library/TpmService is a reference implementation |
| 6 | of the TPM Service Command Response Buffer Interface Over FF-A specification released by |
| 7 | ARM. See [TPM Service Command Response Buffer Interface Over FF-A](https://developer.arm.com/documentation/den0138/0100/?lang=en) |
| 8 | for more details. The specification is meant to describe one approach to TPM integration |
| 9 | on ARM systems, namely firmware-based TPM integration. |
| 10 | |
| 11 | ## Communication |
| 12 | |
| 13 | The TPM service is a way for the normal-world to communicate with a TPM which should only |
| 14 | be accessible via the secure-world (Arm TrustZone). Through the normal mechanism of FF-A |
| 15 | Direct Request messages the normal world can issue the ABIs specified in the CRB over FF-A |
| 16 | specification to communicate with the TPM. |
| 17 | |
| 18 | Communication occurs through a CRB interface which is spec defined via Trusted Computing |
| 19 | Group (TCG) PC Client Specific Platform TPM Profile for TPM 2.0. See |
| 20 | [TCG PC Client Platform TPM Profile Specification for TPM 2.0](https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-Version-1p06_pub.pdf) |
| 21 | for more details. |
| 22 | |
| 23 | The TPM Service State Translation Library found in FfaFeaturePkg/Library/TpmServiceStateTranslationLib |
| 24 | is used to translate the CRB interface into the FIFO interface our QEMU SBSA platform uses |
| 25 | to communicate with the software TPM. See [QEMU TPM Device](https://www.qemu.org/docs/master/specs/tpm.html) |
| 26 | for more details. In short, the TPM is emulated using an external TPM emulator called "swtpm". |
| 27 | This "swtpm" behaves like a hardware TPM and must be initialized/started before attempting to |
| 28 | access it through the TPM emulator in QEMU. Note that building and running QEMU SBSA with |
| 29 | BLD_*_TPM2_ENABLE=TRUE the "swtpm" is automatically initialized and started. If interested, |
| 30 | code for this can be found in QemuRunner.py which is located in Platforms/QemuSbsaPkg/Plugins/QemuRunner |
| 31 | in mu_tiano_platforms. |
| 32 | |
| 33 | The TPM service's CRB is accessible by both the normal-world and secure-world but is completely |
| 34 | managed by the TPM service. Upon initialization of the service the CRB will be initialized. After |
| 35 | the completion of every TPM command, the CRB will be cleaned such that it retains a consistent |
| 36 | state. The idea is that the TPM service's CRB mimics that of a normal MMIO CRB in that all |
| 37 | communication goes through the CRB but instead of acting immediately upon adjustments to register |
| 38 | contents, the TPM service needs to be invoked via the TPM service's commands/ABIs. |
| 39 | |
| 40 | ## Commands |
| 41 | |
| 42 | Only the required commands defined in the CRB over FF-A spec are implemented in the reference |
| 43 | implementation. All of the ABIs related to notifications that are defined in the CRB over FF-A |
| 44 | spec are currently unsupported. |
| 45 | |
| 46 | ### Get Interface Version |
| 47 | |
| 48 | The Get Interface Version ABI returns the version the reference implementation is based on. |
| 49 | The current version reported is v1.0. This is used to distinguish updates to the CRB over FF-A |
| 50 | specification. |
| 51 | |
| 52 | ### Start |
| 53 | |
| 54 | The Start ABI is used to transmit locality requests and TPM commands to the TPM. These |
| 55 | commands are transferred via the CRB to the platform's communication of choice. (PTP CRB, |
| 56 | Mobile CRB, FIFO, TIS) The Start ABI contains a state machine that manages the current |
| 57 | state the TPM is in: Idle, Ready, and Complete. It only transitions to another state upon |
| 58 | successful transmission of the corresponding TPM command. A diagram of the TPM state for |
| 59 | the CRB interface can be found on page 118 of the TCG2 PC Client Spec. (Figure 4) |
| 60 | |
| 61 | Locality requests manage which locality is currently the active locality. (i.e. which |
| 62 | locality is currently in use) This ABI has the capability to either request or relinquish |
| 63 | a locality. Note that to request a differently locality the active locality must first be |
| 64 | relinquished. |
| 65 | |
| 66 | Note that while writing to a different locality is not prevented, no actions will take |
| 67 | place unless the locality is first requested. Any state information written to that |
| 68 | locality will be ignored as well as lost once that locality is requested. |
| 69 | |
| 70 | Reminder that all CRB state information for the active locality will be cleaned after |
| 71 | every invocation of the Start ABI. This is to maintain a consistent and clean internal |
| 72 | state. |
| 73 | |
| 74 | ### Manage Locality |
| 75 | |
| 76 | The Manage Locality ABI has yet to be officially added to the CRB over FF-A specification, |
| 77 | however, there are plans to add it in the future. This ABI is listed under the |
| 78 | IMPLEMENTATION DEFINED section of Function IDs (0x1fxx_xxxx). The availability of the CRB |
| 79 | localities (i.e. whether a locality is opened or closed) is not something that the TPM |
| 80 | service manages. This information is controlled by TF-A at S-EL3. This ABI is used |
| 81 | exclusively by TF-A to inform the TPM service of the availability of each locality. This |
| 82 | ABI has the capability to open and close any locality. |
| 83 | |