qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.vnet.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: anbang.ruan@cs.ox.ac.uk, andreas.niederl@iaik.tugraz.at,
	qemu-devel@nongnu.org, serge@hallyn.com
Subject: Re: [Qemu-devel] [PATCH V10 5/5] Add a TPM Passthrough backend driver implementation
Date: Tue, 27 Sep 2011 13:38:52 -0400	[thread overview]
Message-ID: <4E820A2C.2010909@linux.vnet.ibm.com> (raw)
In-Reply-To: <20110927171339.GB16467@redhat.com>

On 09/27/2011 01:13 PM, Michael S. Tsirkin wrote:
> On Tue, Sep 27, 2011 at 10:50:48AM -0400, Stefan Berger wrote:
>> +Since the host's firmware (BIOS/UEFI) has already initialized the TPM,
>> +the VM's firmware (BIOS/UEFI) will not be able to initialize the
>> +TPM again and may therefore not show a TPM-specific menu that would
>> +otherwise allow the user to configure the TPM.
>> +Also, if TPM ownership is released from within a VM then this will
>> +require a reboot of the host and the user will have to enter the host's
>> +firmware menu to enable and activate the TPM again.
> Rewrite:
>   Further, if TPM ownership is released from within a VM,
>   TPM gets deactivated in host.
Further, if TPM ownership is release from within a VM, the host's TPM 
gets disabled and deactivate.
>   To enable and activate the TPM again afterwards,
>   host has to be rebooted and the user is required to
>   enter the host's firmware menu.
>
>> If the TPM is left
>> +disabled and deactivated most TPM commands will fail.
> Why do we allow guest to do this then?
You cannot prevent it. This is due to how the TPM works. We cannot 
intercept the commands, either, and I don't think it makes much sense. I 
wrote this part of the docs to make people aware of these scenarios so 
they don't come as a surprise.
> Can we return an error, or ignore the release
> command? If someone really wants this unsafe behaviour
> we could make this an option, off by default.
>

In effect you'd have to parse every command that goes from the VM to the 
host and intercept it in the passthrough driver. I don't want to prevent 
it since it's a valid usage scenario but it has side effects (host needs 
to be rebooted). Even if we were to intercept this command then the user 
always has the possibility to send commands in an encrypted form (using 
TPM's transport 'tunnel') where one couldn't intercept this particular 
command anymore. So, my suggestion is we leave it as it is but we make 
people aware of these scenarios.

    Stefan

  reply	other threads:[~2011-09-27 17:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-27 14:50 [Qemu-devel] [PATCH V10 0/5] Qemu Trusted Platform Module (TPM) integration Stefan Berger
2011-09-27 14:50 ` [Qemu-devel] [PATCH V10 1/5] Support for TPM command line options Stefan Berger
2011-09-27 14:50 ` [Qemu-devel] [PATCH V10 2/5] Add TPM (frontend) hardware interface (TPM TIS) to Qemu Stefan Berger
2011-09-27 14:50 ` [Qemu-devel] [PATCH V10 3/5] Add a debug register Stefan Berger
2011-09-27 14:50 ` [Qemu-devel] [PATCH V10 4/5] Build the TPM frontend code Stefan Berger
2011-09-27 14:50 ` [Qemu-devel] [PATCH V10 5/5] Add a TPM Passthrough backend driver implementation Stefan Berger
2011-09-27 17:13   ` Michael S. Tsirkin
2011-09-27 17:38     ` Stefan Berger [this message]
2011-09-27 18:07       ` Michael S. Tsirkin
2011-09-27 18:53         ` 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=4E820A2C.2010909@linux.vnet.ibm.com \
    --to=stefanb@linux.vnet.ibm.com \
    --cc=anbang.ruan@cs.ox.ac.uk \
    --cc=andreas.niederl@iaik.tugraz.at \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=serge@hallyn.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).