- TCG Device Driver Library
- TPM 1.1b Specification Device Interface
- TPM 1.2 Specification Device Interface
- Summary
TPM 1.1b Specification Device Interface
The TCG 1.1b specification was the first TCG TPM standard that was widely available, and many vendors have developed products around that standard. Unfortunately, that standard did not define a mechanism by which to communicate with the actual TPM device. Consequently, each vendor was forced to define a low-level communication interface that was unique to that vendor.
In the following example, we describe the interface to the Atmel 1.1b TPM chip. This TPM device was one of the earliest available and is often used in desktop and notebook computers.
Technical Details
The Atmel 1.1b TPM uses port I/O for communication and does not support interrupts. The port I/O addresses that the device uses are 0x4E, 0x4F, 0x400, and 0x401. The first two ports, 0x4E and 0x4F, are used to query the chip for details such as version number and manufacturer. They are used in an index/data pair configuration and are read as:
int rdx(int index) { outb(index, 0x4E); return inb(0x4F) & 0xFF; }
When read, port address 0x401 acts as the TPM status register. It signals that the TPM is busy (bit 1), or when data is available to be read (bit 2). Writing a value to port 0x401 with the first bit set will cause the TPM to abort the current command that it is executing. Port 0x400 is the data port; it is used to read and write TPM commands from and to the device.
A typical sequence for a TPM device driver is to send a command to the device, wait for a response, and then read the response. Because the Atmel TPM device does not support interrupts, the device driver has to poll the status register to determine whether a response is available. This is a rather inefficient way to wait for a device since, when done incorrectly, it can make the host system unresponsive for a long period of time. This is especially true for a TPM device. The wait time between a send command and a receive response may literally take 60 seconds or more for some operations, such as key generation.
For convenience, we use the following definitions in the code to make it easier to follow:
#define ATMEL_DATA_PORT 0x400 /* PIO data port */ #define ATMEL_STATUS_PORT 0x401 /* PIO status port */ #define ATMEL_STATUS_ABORT 0x01 /* ABORT command (W) */ #define ATMEL_STATUS_BUSY 0x01 /* device BUSY (R) */ #define ATMEL_STATUS_DATA_AVAIL 0x02 /* Data available (R) */
These definitions provide specifics for a particular Atmel TPM. Having that settled, we can now write cleaner code.
Device Programming Interface
The Atmel TPM requires no special initialization for it to work correctly. The LPC bus, on which it resides, is typically already initialized and set up by the system BIOS. To check for the presence of the Atmel TPM, the following check suffices:
int init(void) { /* verify that it is an Atmel part */ if (rdx(4) != 'A' || rdx(5) != 'T' || rdx(6) != 'M' || rdx(7) != 'L') return 0; return 1; }
The Atmel TPM uses the signature "ATML" to signal that the device is present and operating correctly.
The Tddli_TransmitData function consists of two major components: a function to send a command to the TPM device and a function to receive the response from the device. The send command is illustrated next:
int send(unsigned char *buf, int count) { int i; /* send abort and check for busy bit to go away */ outb(ATMEL_STATUS_ABORT, ATMEL_STATUS_PORT); if (!wait_for_status(ATMEL_STATUS_BUSY, 0)) return 0; /* write n bytes */ for (i = 0; i < count; i++) outb(buf[i], ATMEL_DATA_PORT); /* wait for TPM to go BUSY or have data available */ if (!wait_for_not_status(ATMEL_STATUS_BUSY| ATMEL_STATUS_DATA_AVAIL, 0)) return 0; return count; }
The first step of the send function is to ensure that the TPM device is in a well-defined state where it is ready to accept a command. This is achieved by aborting any outstanding command and waiting for the device to become ready. The wait_for_status function does exactly that: It checks the status register for a state change using the condition (status & mask) == value, and if it did not evaluate to true, then it waits for a brief period and tries again. After a while, the function times out and will return 0. If the wait for condition is met, then the function returns 1. In this particular instance, wait_for_status waits for the busy bit to turn off.
Once the TPM device is ready to accept a command, it is simply written to the data port one byte at a time. The command is a TPM blob as defined by the TCG TPM specification. As soon as the command is written, we need to check for either of two conditions: 1) the TPM is processing the command, or 2) the command has already finished and the response is available. We check for these conditions by calling the wait_for_not_status function and test for the busy and available bits. This function is analogous to wait_for_status except that the test condition tests for inequality: (status & mask) != value.
The receive function follows similar concepts but is more complicated because it needs to handle more conditions:
int recv(unsigned char *buf, int count) { unsigned char *hdr = buf; unsigned long size; int i; /* wait while the TPM to respond */ if(!wait_for_status(ATMEL_STATUS_DATA_AVAIL| ATMEL_STATUS_BUSY, ATMEL_STATUS_DATA_AVAIL)) return 0; /* start reading header */ for (i = 0; i < 6; i++) { if ((inb(ATMEL_STATUS_PORT) & ATMEL_STATUS_DATA_AVAIL) == 0) return 0; *buf++ = inb(ATMEL_DATA_PORT); } /* size of the data received */ size = decode_u32(hdr + 2); if (count < size) return 0; /* read all the data available */ for ( ; i < size; i++) { if ((inb(ATMEL_STATUS_PORT) & ATMEL_STATUS_DATA_AVAIL) == 0) return 0; *buf++ = inb(ATMEL_DATA_PORT); } /* sanity check: make sure data available is gone */ if (inb(ATMEL_STATUS_PORT) & ATMEL_STATUS_DATA_AVAIL) return 0; return size; }
Before calling the preceding receive function, you need to make sure that the device is not still busy working on the command itself. You can check this by examining the busy bit in the status command and schedule another task if it is still busy. Some commands can take up to more than a minute to process, so spinning on the busy bit may lead to an unresponsive system.
The first step in the receive function is to ensure that there is a response available and that the TPM is no longer busy processing a request. The next step is to read the response buffer.
Like most 1.1b TPMs, the Atmel TPM does not allow you to query the length of the response without reading the actual data. For this reason, receiving a response from the TPM consists of two parts. During the first part, we read the TPM blob header from the device. This header is always 6 bytes long and contains the total length of the response in a big endian byte order. After the length has been converted to native byte order, we use it in the second part to read the remainder of the response packet.
Although the device interface we described in this section is specific to the Atmel TPM implementation, the concepts and the way to interact with the device are similar for other 1.1b TPMs. Still, each 1.1b TPM requires its own device driver, which is quite a burden for firmware and operating system developers. To eliminate the need for multiple device drivers, TCG defined a single device interface standard for TPMs that follow the TPM 1.2 specification. We will discuss that next.