From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnV4B-00089u-Mt for qemu-devel@nongnu.org; Wed, 29 Apr 2015 12:42:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YnV48-0001Tz-Aa for qemu-devel@nongnu.org; Wed, 29 Apr 2015 12:42:31 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:44435) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnV47-0001Tr-Sn for qemu-devel@nongnu.org; Wed, 29 Apr 2015 12:42:28 -0400 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 29 Apr 2015 10:42:26 -0600 Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 143FA3E4003E for ; Wed, 29 Apr 2015 10:42:23 -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 t3TGg0g235192908 for ; Wed, 29 Apr 2015 09:42:00 -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 t3TGgMKL026677 for ; Wed, 29 Apr 2015 10:42:22 -0600 Message-ID: <554109ED.7050500@linux.vnet.ibm.com> Date: Wed, 29 Apr 2015 12:42:21 -0400 From: Stefan Berger MIME-Version: 1.0 References: <1429137528-1069064-1-git-send-email-stefanb@linux.vnet.ibm.com> <20150416153506.3260becd@nial.brq.redhat.com> <552FC1AF.4030208@linux.vnet.ibm.com> <20150422090001.4191222f@nial.brq.redhat.com> <5537E60F.2050106@linux.vnet.ibm.com> <20150429110644.2000ebb8@nial.brq.redhat.com> In-Reply-To: <20150429110644.2000ebb8@nial.brq.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/5] Extend TPM support with a QEMU-external TPM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: safford@watson.ibm.com, Kevin O'Connor , qemu-devel@nongnu.org, quan.xu@intel.com, mst@redhat.com On 04/29/2015 05:06 AM, Igor Mammedov wrote: > On Wed, 22 Apr 2015 14:18:55 -0400 > Stefan Berger wrote: > >> On 04/22/2015 03:00 AM, Igor Mammedov wrote: >>> On Thu, 16 Apr 2015 10:05:35 -0400 >>> Stefan Berger wrote: >>> >>>> On 04/16/2015 09:35 AM, Igor Mammedov wrote: >>>>> On Wed, 15 Apr 2015 18:38:43 -0400 > [...] >>>>> Is it possible to use MMIO region instead of allocating tpm_ppi_anchor >>>>> and tpm_ppi in BIOS memory? >>>> MMIO region of what? Of the TIS? The TIS doesn't have memory locations >>>> 'just to keep bytes' and they would be cleared upon machine reset / reboot. >>>> >>>> The purpose of the PPI interface is to leave an opcode for the BIOS to >>>> act upon after a reset. So we have to write it into memory that doesn't >>>> get cleared upon reboot. Also, the BIOS leaves a result in memory so we >>>> can read the result code in the OS via sysfs entry. >>> it doesn't matter where opcodes are stored though, they could be stored >>> on QEMU's TPM device (i.e. inside TPM owned MMIO region). That way QEMU >>> will know in advance where opcodes are stored and build ACPI tables >>> with correct address without any need for scanning memory. >> It only matters that these opcodes survive a machine reboot. Some >> devices get reset on the way >> and the choices of suitable NVRAM are limited. >> >> Ok, so we could extend the TPM TIS model with a buffer that can hold >> these opcodes. >> At the moment I think I need 3 bytes. Future specifications may require >> more. We can >> make room for this in the TIS from offset 0xf90-0xfff where we can put >> vendor >> specific extensions. Maybe we just stick it into locality 4 -> 0xfed4 >> 4f90 to 0xfed4 4fff >> and don't reset that memory area ? > yep So we can do it this way ... > >> The only thing that speaks against this is that this would not work if >> SeaBIOS was not >> running on QEMU but on bare metal -- if that was to be a concern at all. >> The current >> solution tried to address this as well, but it would require coreboot >> support and the >> last time I tested this on my Chromebook it looks like an anchor created >> but SeaBIOS >> is not found after a reboot anymore, so it would require some form of >> cooperation >> from coreboot to enable this. So if we ditch this, we can go with a >> buffer in the MMIO. > Coreboot would probably require different ACPI buffer read/write functions, > the rest could stay the same. Yes, understood. >> >> >>> Although it's just another workaround around split brain problem where >>> QEMU owned ACPI tables have to know about guest (BIOS) provided address. >>> >>> >>>> I had previously tried using NVRAM of the TPM to leave that opcode (and >>>> result) , but this doesn't work well due to protection restrictions of >>>> the TPM's NVRAM locations and using the Linux TSS for example non-root >>>> users could then write an opcode into the NVRAM of the TPM (there are >>>> TPM commands to write to the TPM's NVRAM locations and tpm-tools has >>>> tools to write to these locations) that the machine then ends up acting >>>> upon without the admin of the machine wanting that. So, that's not a >>>> choice, either. >>>> >>>> >>>>> That would simplify BIOS part a bit and significantly simplify ACPI code >>>>> as most of it is dealing with figuring out address of tpm_ppi. >>>> Wished it would, but I don't see a way to make it easier. >>> Since ACPI implementation for handling opcodes doesn't interface/depend >>> on TPM device and interfaces only with BIOS it should also be BIOS owned. >>> Cleaner way could be installing an additional BIOS generated table >>> (with correct ADDR) to QEMU provided ACPI tables set. >> Would that be a custom table? Do we need changes for this in the OS >> or can that table be found via ACPI? > It would be just additional SSDT, no OS changes are required. > what you'll need to do is to extend QEMU supplied RSDT to include > pointer to additional SSDT. > I'm not sure where ACPI tables come from in case of coreboot though. > >>> That also would be reusable with coreboot since you will have shared >>> ACPI impl. in SeaBIOS without need to duplicate it in QEMU/coreboot. >> Can you sketch the ACPI code necessary to convey the SeaBIOS / coreboot >> allocated memory address ? How do we write the SeaBIOS allocated >> address into the ACPI code? > grep for acpi_pci64_start in SeaBIOS code, > it should give rough idea how to do it. > > [...] > ... or we can do it this way. Which way now ? My preference is the TIS path, because it seems easier. Now what I am seeing in SeaBIOS is that another SSDT is being built. Would this then be an additional SSDT or would it replace the TPM's SSDT that we're now supplying from QEMU. 2 choices now -- which one to take? Stefan