From: Stefan Berger <stefanb@linux.vnet.ibm.com>
To: kevin@koconnor.net, seabios@seabios.org, mst@redhat.com,
qemu-devel@nongnu.org
Cc: Stefan Berger <stefanb@us.ibm.com>,
stefan.reinauer@coreboot.org, coreboot@coreboot.org
Subject: Re: [Qemu-devel] [RFC PATCH 1/1] TPM: Support Physical Presence Interface Spec
Date: Thu, 11 Sep 2014 10:52:37 -0400 [thread overview]
Message-ID: <5411B735.9050001@linux.vnet.ibm.com> (raw)
In-Reply-To: <1409668064-14371-1-git-send-email-stefanb@us.ibm.com>
On 09/02/2014 10:27 AM, Stefan Berger wrote:
> From: Stefan Berger <stefanb@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
prev parent reply other threads:[~2014-09-11 14:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-02 14:27 [Qemu-devel] [RFC PATCH 1/1] TPM: Support Physical Presence Interface Spec Stefan Berger
2014-09-11 14:52 ` Stefan Berger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5411B735.9050001@linux.vnet.ibm.com \
--to=stefanb@linux.vnet.ibm.com \
--cc=coreboot@coreboot.org \
--cc=kevin@koconnor.net \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=seabios@seabios.org \
--cc=stefan.reinauer@coreboot.org \
--cc=stefanb@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).