From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YznmT-0001ie-4R for qemu-devel@nongnu.org; Tue, 02 Jun 2015 11:07:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YznmP-0002EI-PC for qemu-devel@nongnu.org; Tue, 02 Jun 2015 11:07:05 -0400 Received: from e18.ny.us.ibm.com ([129.33.205.208]:53538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YznmP-0002E9-Lt for qemu-devel@nongnu.org; Tue, 02 Jun 2015 11:07:01 -0400 Received: from /spool/local by e18.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 2 Jun 2015 11:07:01 -0400 Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 9DABD38C8026 for ; Tue, 2 Jun 2015 11:06:59 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t52F6x1v54984780 for ; Tue, 2 Jun 2015 15:06:59 GMT Received: from d01av01.pok.ibm.com (localhost [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t52F6ubi018547 for ; Tue, 2 Jun 2015 11:06:59 -0400 Message-ID: <556DC68E.8090608@linux.vnet.ibm.com> Date: Tue, 02 Jun 2015 11:06:54 -0400 From: Stefan Berger MIME-Version: 1.0 References: <1432676024-1046793-1-git-send-email-stefanb@linux.vnet.ibm.com> <1432676024-1046793-4-git-send-email-stefanb@linux.vnet.ibm.com> <20150531181159.GH5268@redhat.com> <556D1EDE.8060100@linux.vnet.ibm.com> <20150602110702-mutt-send-email-mst@redhat.com> <556DAE20.5070709@linux.vnet.ibm.com> <20150602152340-mutt-send-email-mst@redhat.com> <556DBDA4.2040202@linux.vnet.ibm.com> <20150602163822-mutt-send-email-mst@redhat.com> In-Reply-To: <20150602163822-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 3/6] Support Physical Presence Interface Spec List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: imammedo@redhat.com, Kevin O'Connor , qemu-devel@nongnu.org, quan.xu@intel.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 >>>>>>>> Cc: Michael Tsirkin >>>>>>>> Cc: Kevin O'Connor >>>>>>> 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.