[coreboot] [RFC PATCH 1/1] TPM: Support Physical Presence Interface Spec
Stefan Berger
stefanb at linux.vnet.ibm.com
Thu Sep 11 16:52:37 CEST 2014
On 09/02/2014 10:27 AM, Stefan Berger wrote:
> From: Stefan Berger <stefanb at linux.vnet.ibm.com>
>
> 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
More information about the coreboot
mailing list