From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XS5k0-0006ob-BP for qemu-devel@nongnu.org; Thu, 11 Sep 2014 10:53:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XS5jn-0002SH-IA for qemu-devel@nongnu.org; Thu, 11 Sep 2014 10:52:56 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:55549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XS5jn-0002RX-Cx for qemu-devel@nongnu.org; Thu, 11 Sep 2014 10:52:43 -0400 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 11 Sep 2014 10:52:41 -0400 Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 7B90A6E8041 for ; Thu, 11 Sep 2014 10:52:27 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s8BEqcIu3735892 for ; Thu, 11 Sep 2014 14:52:39 GMT Received: from d01av02.pok.ibm.com (localhost [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s8BEqcnm003156 for ; Thu, 11 Sep 2014 10:52:38 -0400 Message-ID: <5411B735.9050001@linux.vnet.ibm.com> Date: Thu, 11 Sep 2014 10:52:37 -0400 From: Stefan Berger MIME-Version: 1.0 References: <1409668064-14371-1-git-send-email-stefanb@us.ibm.com> In-Reply-To: <1409668064-14371-1-git-send-email-stefanb@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 1/1] TPM: Support Physical Presence Interface Spec List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: kevin@koconnor.net, seabios@seabios.org, mst@redhat.com, qemu-devel@nongnu.org Cc: Stefan Berger , stefan.reinauer@coreboot.org, coreboot@coreboot.org On 09/02/2014 10:27 AM, Stefan Berger wrote: > From: Stefan Berger > > To (try to) avoid SeaBIOS from having to implement a menu for managing the > various states of a TPM device, implement the TCG Physical Presence Interface > Specification that allows a root user on Linux (for example) to set the 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 operation 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 > ppi > > This ACPI implementation writes the opcode into the TPM's NVRAM at index > 0x5001 0000 (to be adapted), which SeaBIOS can then read and react to. > An alernative would be to have ACPI write the byte into a memory area that > SeaBIOS would have to be able to find upon reboot. > > More than a single byte of persistent memory will be needed once SeaBIOS > supports this since it must store a status byte about the last operation, > the opcode that was acted on, and the return code that the TPM gave > (see ACPI function 5). > > Only a subset of the defined opcodes will be supported. Tentatively opcodes > 1-11, 14 will be supported. So here now for my own comments: The above referenced spec defines the NVRAM area 0x5001 0000 to be used for "BIOS TPM Management flags" (page 5/35). The particular problem with this NVRAM area is that this particular area would have to be defined during TPM manufacturing due to bit 28 set in this index, which has a particular meaning. Defining it in a software TPM is easy, but doesn't address TPMs out there in the field and the TPMs I looked at do not define this area. We could use NVRAM area 0x4001 0000 instead, which could be created by the BIOS if not found. The next question then is about the choice of protection flags to be used for this area. In general 4 different types of flags exist for allowing writing to an NVRAM area: writing only under physical presence, writing with NVRAM area authentication, writing with authentication using the owner password, or 'WRITEDEFINE'. This is described in the TPM specs in section 20.1 action 9d. (http://www.trustedcomputinggroup.org/resources/tpm_main_specification -- part 3 - commands). For ACPI anything with authentication seems too complicated since a session would have to be opened and usage of hashing is required. Only allowing writing to the area during physical presence is also not possible when the OS is running (BIOS gives up physical presence). So what remains is 'WRITEDEFINE', which allows to lock the area permanently once '0' bytes are written to it. This also seems impractical since anyone could now stop the mechanism from working. So, to implement this spec., the only option seems to be to have a reserved memory area allocated by the BIOS for the ACPI code to write data into. The BIOS would then have to know the address and find the data on reboot. SeaBIOS could try to reserve such an area, find the SSDT for the TPM and overwrite a special marker (address) left in the TPM's SSDT, such as an address like 0x12345678, which would presumably be visible after compilation. Thoughts? Regards, Stefan