CRB interface support
Status: Beta
Brought to you by:
kagoldman
Menu
▾
▴
Does this reference swTPM code already support the CRB interface or something that would need to be implemented?
This core SW TPM uses a socket interface. There is a separate project at https://github.com/stefanberger/libtpms that layers a Linux /dev/tpm0 on top of the core TPM.
I think that lower layers like TIS vs CRB are hidden from the device driver API.
I think the linux TPM dernel device driver does already support CRB to commmunicate to a tpm device (whether discreet or ftpm). My question was more of whether some additional logic would also need to be added to this SWTPM code to be able to support communicating with the CRB interface as well to consume the command request and return the response to the callee, and from your reply it seems like the answer would be yes.
I think the answer is more, "I don't understand the question." To a Linux application, the TPM appears at /dev/tpm0 and supports the usual open,read,write,close calls. How the packets get to the TPM is hidden from the application by the device driver.
The TIS and CRB communicate to the TPM through certain hardware registers at fixed hardware addresses. The SW TPM doesn't have those.
Agreed that the Linux application or even the TPM-TSS stack is abstracted away from having to understand the CRB or TIS interface hidden by the device driver. So essentially I'm trying to use the swTPM code to implement a TA running within a ARM Trustzone TEE. My plan is to use the CRB interface (defined as memory mapped region in Normal World that is accisible by the TEE in Secure World) as a mechanism for the Linux TPM kernel driver send TPM commands and get responses to/from the TA running in OPTEE with the help of ARM SMC to switch between the two world. I believe this is similiar to how microsoft implemented their fTPM solution on Surface Pro based on ARM. That is why I asked if this swTPM code already supports the CRB interface.
Sorry, it doesn't. Perhaps https://github.com/stefanberger/libtpms/tree/tpm2-preview.rev146 will give you some hints.
I also wonder if it would be easier to just implement an interface that sends command packets and gets response packets, similar to the currect socket interface. It may be easier that simulating the entire HW TPM register set.