qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH v3 3/6] Support Physical Presence Interface Spec
Date: Tue, 02 Jun 2015 10:28:52 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 06/02/2015 09:30 AM, Michael S. Tsirkin wrote:
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 <address@hidden>
Cc: Michael Tsirkin <address@hidden>
Cc: Kevin O'Connor <address@hidden>
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).

We would need to create an XSDT with at least two entries, one pointing to the existing FADT (per spec) and one to this new table with what signature? Do you have a pointer to a table structure identifiable by UEFI signature and GUID to see how this looks like? ACPI will identify it by triple signature, though, right ? Should the XSDT always be there or only if we have a TPM?

How would I mark the DataTableRegion as AddressRangeReserved or would it automatically be?

Would the ACPI code then internally walk the list of tables attached to the XSDT and find the address of that table and make it available so that we can define a Field() on it. Assuming the DataTableRegion is called AAAA, would we then define a Field(AAAA, AnyAcc,...) on it?

Well, I am not sure how involved this is going to be, so maybe I would defer this ACPI support for now unless we could live with the proposed solution and UEFI could use it as well when run on QEMU. And I am glad that I haven't converted the ASL to C code, because this would make it a lot more difficult to develop and debug...

     Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]