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

[Stefan Berger <stefanb@linux.vnet.ibm.com>]

On 06/02/2015 10:46 AM, Michael S. Tsirkin wrote:
> 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 <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).
>> 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.

Thanks. UEFI is the signature. OemTableIDString would have to be the 
unique part. I don't see a GUID  -- so not sure how to weave this in 
unless it goes into the Data area.



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

So you'll add that then? Then let me defer the ACPI support for now.


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


just by being marked as reserved via e820 ?

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

Ok, so it looks like the offset where the stuff then goes would be at 
offset 54.