From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42967) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yzm9Y-0002f0-0r for qemu-devel@nongnu.org; Tue, 02 Jun 2015 09:22:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yzm9U-0000Zr-Lo for qemu-devel@nongnu.org; Tue, 02 Jun 2015 09:22:47 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:34945) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yzm9U-0000Zn-Dt for qemu-devel@nongnu.org; Tue, 02 Jun 2015 09:22:44 -0400 Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 2 Jun 2015 07:22:43 -0600 Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id ECA021FF0049 for ; Tue, 2 Jun 2015 07:13:51 -0600 (MDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t52DM8JF17367258 for ; Tue, 2 Jun 2015 06:22:08 -0700 Received: from d03av05.boulder.ibm.com (localhost [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t52DMfj6024548 for ; Tue, 2 Jun 2015 07:22:41 -0600 Message-ID: <556DAE20.5070709@linux.vnet.ibm.com> Date: Tue, 02 Jun 2015 09:22:40 -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> In-Reply-To: <20150602110702-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 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