Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0

Locality of Command

The 1.2 design had a characteristic called locality that was used to designate which software stack originated a command when it was sent to the TPM. The main usage in 1.2 was to provide proof that a command originated when the CPU was in a peculiar mode caused by entering either the Intel TXT or AMD-V command (in Intel or AMD processors, respectively). These commands are used for the Dynamic Root of Trust Measurement (DRTM) when the machine is put into a vanilla trusted state while in the midst of operations, so that the state of the machine's software can be reported in a trusted manner.

In 2.0, just as PCR assertions are extended for use whenever authorization can be used, locality is extended to a general-purpose assertion. When locality is used as an assertion in a policy, the session policy digest is extended with TPM_CC_PolicyLocality || locality(ies).

When using the trial session to calculate the policy, you execute the command TPM2_PolicyLocality, passing in the handle of the trial session and the locality structure, TPMA_LOCALITY, found in part 2 of the specification.

When satisfying a locality for a session, the user uses TPM2_PolicyLocality to pass the localities to which the session is to be bound. Then two things happen:

1. The session digest is extended with TPM_CC_PolicyLocality

|| locality(ies).

2. A session variable is set, recording the locality passed in.

When a command is then executed with that session, the locality from which the command is coming is compared to the locality variable set in the session. If they don't match, the command will not execute.

In the 1.2 specification, there were five localities—0, 1, 2, 3, and 4—which were represented by a bitmap in a single byte. This allowed you to select several localities at a time: for example, 0b00011101 represented the selection of localities 0, 2, 3, and 4. In the 2.0 specification, this result can be easily achieved using the PolicyOr command; but to reduce the cognitive load on people moving from 1.2 to 2.0, the localities 0–4 are represented the same way as before.

The problem with this solution is that it limits the number of localities available. It was possible to add three more localities, represented by bits 5, 6, and 7. However, the mobile and virtualization workgroups in TCG wanted more. This resulted in a bit of a hack in the specification. To extend the number of localities, the byte values above the fifth bit are used to represent single localities. This results in localities of the form 0, 1, 2, 3, 4, 32, 33, 34, ...255. That is, there is no way to represent localities 5–31. This is shown in Table 14-2. Note the change that happens when the value is 32.

Table 14-2. Locality Representations and the Locality(ies) They Represent


Binary Representation

Locality(ies) Represented






Locality 0



Locality 1



Localities 0, 1



Locality 2



Localities 0, 2



Localities 1, 2



Localities 0, 1, 2



Locality 3


. . .

. . .



Localities 0, 1, 2, 3, 4



Locality 32



Locality 33



Locality 34


. . .

. . .



Locality 255

Localities can be used in a number of places. They can represent the origin of a command used to create an entity. They can also be used to lock functions so they can be used only if the command originates from a certain location. In 1.2, the locality was used to allow the CPU to control resetting and extending certain PCRs (for example, 17 and 18) to record putting the PC in a known state before doing a DRTM. Trusted Boot (tboot) is a program available on SourceForge [1] that shows how this is used; Flicker, [2] a program from CMU, used tboot to do run security-sensitive operations in a memory space separate from the OS.

Localities therefore tell the TPM where a command originated. The TPM inherently knows the values of its internal data, and localities can also be used for authorization restrictions.

  • [1]
  • [2]
< Prev   CONTENTS   Next >

Related topics