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

[Michael S. Tsirkin]

On Tue, Jun 02, 2015 at 10:28:52AM -0400, Stefan Berger wrote:
> 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?

I think XSDT has same content as RSDT + new tables from ACPI 2 spec.

> Do you have a pointer to a table structure identifiable by UEFI signature
> and GUID to see how this looks like?

Look it up in Appendix O (that a letter O, not zero) in the UEFI spec.

> ACPI will identify it by triple
> signature, though, right ?  Should the XSDT always be there or only if we
> have a TPM?

I'm looking at adding it unconditionally, this let us use ACPI 2
funcitonality without crashing XP guests.

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

It's automatically either AddressRangeReserved or AddressRangeNVS.
It doesn't look like you have control over which it is.
seabios makes it reserved, nvs makes it 

> 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.

Yes.

> Assuming the DataTableRegion is called AAAA, would
> we then define a Field(AAAA, AnyAcc,...) on it?

Exactly.

> 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