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

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

On Tue, Jun 02, 2015 at 09:22:40AM -0400, Stefan Berger wrote:
> On 06/02/2015 05:15 AM, Michael S. Tsirkin wrote:
> >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?
> 
> 
> They won't persist. If one powers down the physical machine, this won't work
> or not that I would know of that it would have to work.
> 
> 
> >
> >>>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.
> >
> 
> How would the BIOS then find that memory (so it can read the command code
> and act on it)? Would it need to walk ACPI tables or how would it find the
> base address?
> 
>     Stefan

This is similar to things like suspend/resume.

The bios walks the list of the tables RSDP->XSDT, and locates the
data table either by triple signature/vendorid/vendortableid,
or by detecting a UEFI signature and locating the matching GUID
(second option is preferable given current OVMF code).



-- 
MST