From: Stefan Berger <stefanb@linux.vnet.ibm.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: safford@watson.ibm.com, Kevin O'Connor <kevin@koconnor.net>,
qemu-devel@nongnu.org, quan.xu@intel.com, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH 0/5] Extend TPM support with a QEMU-external TPM
Date: Wed, 22 Apr 2015 14:18:55 -0400 [thread overview]
Message-ID: <5537E60F.2050106@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150422090001.4191222f@nial.brq.redhat.com>
On 04/22/2015 03:00 AM, Igor Mammedov wrote:
> On Thu, 16 Apr 2015 10:05:35 -0400
> Stefan Berger <stefanb@linux.vnet.ibm.com> wrote:
>
>> On 04/16/2015 09:35 AM, Igor Mammedov wrote:
>>> On Wed, 15 Apr 2015 18:38:43 -0400
>>> Stefan Berger <stefanb@linux.vnet.ibm.com> wrote:
>>>
>>>> The following series of patches extends TPM support with an
>>>> external TPM that offers a Linux CUSE (character device in userspace)
>>>> interface. This TPM lets each VM access its own private vTPM.
>>>> The CUSE TPM supports suspend/resume and migration. Much
>>>> out-of-band functionality necessary to control the CUSE TPM is
>>>> implemented using ioctl's.
>>>>
>>>> The series extends the TPM support so far that most functionality of
>>>> TPM support on a physical platform is now available to each x86 VM,
>>>> this includes the Physical Presence Interface support that has
>>>> its counter-part in the SeaBIOS and is implemented using ACPI.
>>>>
>>>> http://www.seabios.org/pipermail/seabios/2015-March/008978.html
>>> is it already merged?
>> No, not yet. :-(
>>
>>> 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 ?
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.
>
> 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?
>
> 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?
>
> PS:
> Is it possible to shovel BIOS side TPM code into option rom
> so that it will be loaded only when TPM is present and keep
> BIOS small in case TPM is not required?
There are several places in core SeaBIOS where we jump into TPM related
code
for taking measurements. See this patch. TPM support is isolated with a
config
option and does not take much space if the user chooses not to compile
it in.
http://www.seabios.org/pipermail/seabios/2015-March/008979.html
Stefan
>> So the first time one looks into the sysfs ppi entries [on Linux] it may
>> take a few seconds until the anchor is found. Subsequently the memory
>> location is cached and operations go a lot faster.
>>
>> Stefan
>>
>>>> Stefan Berger (5):
>>>> Provide support for the CUSE TPM
>>>> Support Physical Presence Interface Spec
>>>> Introduce condition to notifiy waiters of completed command
>>>> Introduce condition in TPM backend for notification
>>>> Add support for VM suspend/resume for TPM TIS
>>>>
>>>> hmp.c | 6 +
>>>> hw/i386/acpi-tpm-core.dsl | 277 +++++++++++++++++++++++++++++
>>>> hw/i386/acpi-tpm2.dsl | 27 +++
>>>> hw/i386/q35-acpi-dsdt.dsl | 1 +
>>>> hw/i386/ssdt-tpm.dsl | 12 +-
>>>> hw/tpm/tpm_int.h | 4 +
>>>> hw/tpm/tpm_ioctl.h | 178 +++++++++++++++++++
>>>> hw/tpm/tpm_passthrough.c | 410 +++++++++++++++++++++++++++++++++++++++++--
>>>> hw/tpm/tpm_tis.c | 152 +++++++++++++++-
>>>> hw/tpm/tpm_tis.h | 2 +
>>>> hw/tpm/tpm_util.c | 206 ++++++++++++++++++++++
>>>> hw/tpm/tpm_util.h | 7 +
>>>> include/sysemu/tpm_backend.h | 12 ++
>>>> qapi-schema.json | 17 +-
>>>> qemu-options.hx | 21 ++-
>>>> qmp-commands.hx | 2 +-
>>>> tpm.c | 11 +-
>>>> 17 files changed, 1316 insertions(+), 29 deletions(-)
>>>> create mode 100644 hw/i386/acpi-tpm-core.dsl
>>>> create mode 100644 hw/i386/acpi-tpm2.dsl
>>>> create mode 100644 hw/tpm/tpm_ioctl.h
>>>>
>
next prev parent reply other threads:[~2015-04-22 18:19 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-15 22:38 [Qemu-devel] [PATCH 0/5] Extend TPM support with a QEMU-external TPM Stefan Berger
2015-04-15 22:38 ` [Qemu-devel] [PATCH 1/5] Provide support for the CUSE TPM Stefan Berger
2015-04-15 22:38 ` [Qemu-devel] [PATCH 2/5] Support Physical Presence Interface Spec Stefan Berger
2015-04-15 22:38 ` [Qemu-devel] [PATCH 3/5] Introduce condition to notifiy waiters of completed command Stefan Berger
2015-04-15 22:38 ` [Qemu-devel] [PATCH 4/5] Introduce condition in TPM backend for notification Stefan Berger
2015-04-15 22:38 ` [Qemu-devel] [PATCH 5/5] Add support for VM suspend/resume for TPM TIS Stefan Berger
2015-04-16 13:35 ` [Qemu-devel] [PATCH 0/5] Extend TPM support with a QEMU-external TPM Igor Mammedov
2015-04-16 14:05 ` Stefan Berger
2015-04-22 7:00 ` Igor Mammedov
2015-04-22 18:18 ` Stefan Berger [this message]
2015-04-29 9:06 ` Igor Mammedov
2015-04-29 16:42 ` Stefan Berger
2015-05-04 9:16 ` Igor Mammedov
2015-05-04 15:22 ` Stefan Berger
2015-05-04 16:16 ` Kevin O'Connor
2015-05-04 18:39 ` Stefan Berger
2015-05-04 21:41 ` Igor Mammedov
2015-05-05 2:50 ` Kevin O'Connor
2015-05-05 17:42 ` Stefan Berger
2015-04-16 18:55 ` Michael S. Tsirkin
2015-04-16 19:21 ` Stefan Berger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5537E60F.2050106@linux.vnet.ibm.com \
--to=stefanb@linux.vnet.ibm.com \
--cc=imammedo@redhat.com \
--cc=kevin@koconnor.net \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quan.xu@intel.com \
--cc=safford@watson.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).