Re: [Qemu-devel] [PATCH v3 3/6] Support Physical Presence Interface Spec

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Jun 01, 2015 at 11:11:26PM -0400, Stefan Berger wrote:
> On 05/31/2015 02:11 PM, Michael S. Tsirkin wrote:
> >On Tue, May 26, 2015 at 05:33:41PM -0400, Stefan Berger wrote:
> >>For automated management of a TPM device, implement the TCG Physical Presence
> >>Interface Specification that allows a root user on Linux (for example) to set
> >>an 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 operations 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 > request
> >>
> >>This ACPI implementation assumes that the underlying firmware (SeaBIOS)
> >>has 'thrown an anchor' into the f-segment. The anchor is identified by
> >>two signatures (TCG_MAGIC) surrounding a 64bit pointer. The structure
> >>in the f-segment is write-protected and holds a pointer to a structure
> >>in high memmory
> >memory
> >
> >>area where the ACPI code writes the opcode into and
> >>where it can read the last response from the BIOS.
> >>
> >>The supported opcodes are 1-11, 14, and 21-22. (see table 2 in spec)
> >>Also '0' is supported to 'clear' an intention.
> >>
> >>
> >No need for 2 empty spaces.
> >
> >>Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> >>Cc: Michael Tsirkin <mst@redhat.com>
> >>Cc: Kevin O'Connor <kevin@koconnor.net>
> >All this seems somewhat messy.  Is this FSEG trick what the spec says,
> >or is this a QEMU specific protocol?
> 
> Actually, the text in the patch is outdated. We now moved the area where the
> data are exchanged between ACPI and BIOS into registers provided by the TIS
> -- custom registers in an area that is vendor-specific, so yes, this is a
> QEMU specific solution. The address range for this is fixed and known to
> SeaBIOS and QEMU. Those registers also won't reset upon machine reboot.

Hmm. One way to do a machine reboot is to exit QEMU
then restart it. Where do these registers persist?

> >Would DataTableRegion not be a better way to locate things in
> >memory?
> 
> As I said, we now move that into a memory region provide by the TIS..
> Otherwise I am not very familiar with DataTableRegion.
> 
> Thanks for the comments!
> 
>     Stefan

A data table is a structure that you define (as opposed to code).
Using linker you can allocate some memory and put a pointer
there, then use DataTableRegion to read that pointer value.

-- 
MST