Re: [Qemu-devel] [RFC PATCH 1/1] TPM: Support Physical Presence Interface Spec

[Stefan Berger]

On 09/02/2014 10:27 AM, Stefan Berger wrote:
> From: Stefan Berger <address@hidden>
>
> To (try to) avoid SeaBIOS from having to implement a menu for managing the
> various states of a TPM device, implement the TCG Physical Presence Interface
> Specification that allows a root user on Linux (for example) to set the opcode
> for a sequence of TPM operations that the BIOS is supposed to execute upon
> reboot of the physical or virtual machine. A sequence of operation may for
> example involve giving up ownership of the TPM and activating and enabling the
> device.
>
> The sequences of operations are defined in table 2 in the specs to be found
> at the following link:
>
> http://www.trustedcomputinggroup.org/resources/tcg_physical_presence_interface_specification
>
> As an example, in recent versions of Linux the opcode (5) can be set as
> follows:
>
> cd /sys/devices/pnp0/00\:04/ppi
>
> echo 5 > ppi
>
> This ACPI implementation writes the opcode into the TPM's NVRAM at index
> 0x5001 0000 (to be adapted), which SeaBIOS can then read and react to.
> An alernative would be to have ACPI write the byte into a memory area that
> SeaBIOS would have to be able to find upon reboot.
>
> More than a single byte of persistent memory will be needed once SeaBIOS
> supports this since it must store a status byte about the last operation,
> the opcode that was acted on, and the return code that the TPM gave
> (see ACPI function 5).
>
> Only a subset of the defined opcodes will be supported. Tentatively opcodes
> 1-11, 14 will be supported.

So here now for my own comments:

The above referenced spec defines the NVRAM area 0x5001 0000 to be used 
for "BIOS TPM Management flags" (page 5/35). The particular problem with 
this NVRAM area is that this particular area would have to be defined 
during TPM manufacturing due to bit 28 set in this index, which has a 
particular meaning. Defining it in a software TPM is easy, but doesn't 
address TPMs out there in the field and the TPMs I looked at do not 
define this area. We could use NVRAM area 0x4001 0000 instead, which 
could be created by the BIOS if not found. The next question then is 
about the choice of protection flags to be used for this area. In 
general 4 different types of flags exist for allowing writing to an 
NVRAM area: writing only under physical presence, writing with NVRAM 
area authentication, writing with authentication using the owner 
password, or 'WRITEDEFINE'. This is described in the TPM specs in 
section 20.1 action 9d. 
(http://www.trustedcomputinggroup.org/resources/tpm_main_specification 
-- part 3 - commands). For ACPI anything with authentication seems too 
complicated since a session would have to be opened and usage of hashing 
is required. Only allowing writing to the area during physical presence 
is also not possible when the OS is running (BIOS gives up physical 
presence). So what remains is 'WRITEDEFINE', which allows to lock the 
area permanently once '0' bytes are written to it. This also seems 
impractical since anyone could now stop the mechanism from working.

So, to implement this spec., the only option seems to be to have a 
reserved memory area allocated by the BIOS for the ACPI code to write 
data into. The BIOS would then have to know the address and find the 
data on reboot. SeaBIOS could try to reserve such an area, find the SSDT 
for the TPM and overwrite a special marker (address) left in the TPM's 
SSDT, such as an address like 0x12345678, which would presumably be 
visible after compilation.

Thoughts?

Regards,
   Stefan