Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0

Resource Manager

The RM is responsible for transparently handling all the details of swapping objects, sessions, and sequences in and out of the TPM. Very highly embedded, single-user applications may choose to handle these tasks themselves, but, as discussed previously, most systems are multiuser and require an RM. As an analogy, imagine if all PC applications had to manage memory swapping in and out of memory and the hard disk themselves instead of relying on the operating system to do this. The RM performs a similar function for processes that access TPMs.

Resource Manager Operations

At the risk of stating the obvious, if a transient entity is used in a command, it must be loaded into TPM memory. This means that an RM must parse the command byte stream before the command is sent to the TPM and take any actions required to ensure that all transient objects used by that command are loaded into the TPM. This includes all sessions referenced in the authorization area and all objects, sessions, and sequences whose handles are in the command's handle area.

The basic operations that an RM must perform are as follows [1]:

• Virtualize all object and sequence handles sent to and received from the TPM. Because more of these can be active than can be in the TPM's internal memory, they must be virtualized. [2]

• Maintain tables to keep track of contexts for objects and sequences.

• Maintain a virtual-to-TPM handle mapping for objects and sequences that are loaded in the TPM.

• For commands being sent to the TPM:

• Capture all command byte streams before they're sent to the TPM.

• Check for any handles in the authorization area or handle area. If these handles represent objects, sequences, or sessions, ensure that the saved contexts for these are loaded into the TPM so that the command can successfully execute. For objects and sequences, replace the virtual handles in the command byte stream with the real handles returned from the load commands before sending the command to the TPM.

Note Session handles do not need to be virtualized, because they are constant for the lifetime of the session: that is, when a session is reloaded, it keeps the same handle. the “why” of this is discussed later. For now, it's sufficient to understand the difference between objects and sequences, which get new handles every time they're context loaded, and sessions, which do not.

• For responses from the TPM:

• Capture these responses before they are returned to higher layers of software.

• Virtualize any object or sequence handles in the responses, and replace the handles returned by the TPM in the response byte stream with these virtualized handles.

• It must either proactively guarantee that commands will never fail due to being out of memory in the TPM or reactively fix the

problem when the required contexts can't be loaded into the TPM.

• There are two possible ways to implement the proactive approach:

• The simplest proactive approach requires that, after completion of each TPM command from software layers above the RM, all objects, sessions, and sequences must be context saved and removed from TPM internal memory. This is inherently a simpler approach, but it does cause more commands to be sent to the TPM. For example, after a load command for an object, the object is unloaded even though it might be used in the next command.

• The second proactive approach is to examine the command's handle and session area before executing it, to find all the objects, sequences, and sessions that must be loaded into the TPM. Next, enough of the objects, sequences, and sessions currently loaded into the TPM are evicted that the required ones can be context loaded. Then the required ones that aren't already loaded into the TPM are loaded.


a hardware-triggered command, _TPM_Hash_Start, is discussed later in this

chapter. this command implicitly, and transparently to the rM, evicts an object or session. this imposes some special requirements on the second type of proactive approach.

• The reactive approach takes actions after a command fails when the response code indicates that the TPM was out of memory. When this type of error code is received, the RM must remove objects, sessions, or sequences until enough memory is freed to load the objects, sessions, and sequences required for the current command. Then the original command must be replayed.

Note From hard-earned experience, the reactive approach is extremely difficult to code and even harder to debug. I highly recommend one of the proactive approaches. I tried the reactive approach and it didn't end well, resulting in a recoding effort. enough said.

• The RM must properly handle object, sequence, and session contexts across reset events, as described in the previous section.

The above covers the basic requirements. Others for handling corner cases and some more esoteric functionality are detailed in the “TSS TAB and Resource Manager Specification”.

Now let's examine the TPM features that support RMs.

  • [1] For a reference implementation of a resource manager see the Test/tpmclient/ResourceMgr directory in the SAPI library and test code. The location for this was described in Chapter 7.
  • [2] TPM handle virtualization is not to be confused with OS level virtualization of hardware or operating systems.
< Prev   CONTENTS   Next >

Related topics