xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Shuaijun Zhang <szhang@research.ait.ie>
Cc: xen-devel@lists.xen.org
Subject: [PATCH] docs/vtpm: explain dom0 physical TPM access caveats
Date: Wed, 12 Mar 2014 10:37:40 -0400	[thread overview]
Message-ID: <53207134.5020009@tycho.nsa.gov> (raw)
In-Reply-To: <20140312135145.GD3245@phenom.dumpdata.com>

On 03/12/2014 09:51 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 12, 2014 at 12:32:24PM +0000, Shuaijun Zhang wrote:
>> Hi There,
>>
>> In the document of VTPM (http://xenbits.xen.org/docs/unstable/misc/vtpm.txt
>> ): The Linux dom0 kernel should not try accessing the TPM while the
>> vTPM Manager
>> domain is accessing it.
>>
>> Anyone knows the reason why the dom0 should not access the TPM while vTPM
>> Mgr is accessing it?
>
> Lets rope in the maintainer. Perhaps the doc should be updated to explain
> this.
>
>>
>> Thanks & Regards,
>> Jason

I agree; this docs patch explains the reasoning behind the original guidance
and addresses use cases that cannot yet be handled by a virtual TPM.

----------------------------->8--------------------------------

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
  docs/misc/vtpm.txt | 22 ++++++++++++++++++----
  1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/docs/misc/vtpm.txt b/docs/misc/vtpm.txt
index df1dfae..d20b424 100644
--- a/docs/misc/vtpm.txt
+++ b/docs/misc/vtpm.txt
@@ -120,10 +120,24 @@ the stubdom tree.
  Compiling the LINUX dom0 kernel:
  --------------------------------
  
-The Linux dom0 kernel should not try accessing the TPM while the vTPM
-Manager domain is accessing it; the simplest way to accomplish this is
-to ensure the kernel is compiled without a driver for the TPM, or avoid
-loading the driver by blacklisting the module.
+Because the TPM manager uses direct access to the physical TPM, it may interfere
+with access to the TPM by dom0.  The simplest solution for this is to prevent
+dom0 from accessing the physical TPM by compiling the kernel without a driver or
+blacklisting the module.  If dom0 needs a TPM but does not need to use it during
+the boot process (i.e. it is not using IMA), a virtual TPM can be attached to
+dom0 after the system is booted.
+
+Because the TPM manager does not yet accept requests for deep quotes, if a quote
+or other request needs to be fulfilled by the physical TPM, dom0 will need to
+access the physical TPM.  In order to prevent interference, the TPM Manager and
+dom0 should use different values for the TPM's locality; since Linux always uses
+locality 0, using locality 2 for the TPM Manager is recommended.  If both Linux
+and the TPM Manager attempt to access the TPM at the same time, the TPM device
+will return a busy status; some applications will consider this a fatal error
+instead of retrying the command at a later time.  If a vTPM gets an error when
+loading its key, it will currently generate a fresh vTPM image (with a new EK,
+SRK, and blank NVRAM).
+
  
  Compiling the LINUX domU kernel:
  --------------------------------

  parent reply	other threads:[~2014-03-12 14:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-12 12:32 Question about VTPM Implementation Shuaijun Zhang
2014-03-12 13:51 ` Konrad Rzeszutek Wilk
2014-03-12 14:35   ` Ian Campbell
2014-03-12 14:37   ` Daniel De Graaf [this message]
2014-03-12 15:20     ` [PATCH] docs/vtpm: explain dom0 physical TPM access caveats Shuaijun Zhang
2014-03-12 16:36     ` Shuaijun Zhang
2014-03-12 18:39       ` Daniel De Graaf
2014-03-12 23:04         ` Shuaijun Zhang
2014-03-12 23:41           ` Daniel De Graaf
2014-03-13 11:10     ` Ian Campbell
2014-03-13 14:53       ` Daniel De Graaf
2014-03-13 15:59         ` Ian Campbell
2014-03-14 11:01           ` Ian Campbell

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=53207134.5020009@tycho.nsa.gov \
    --to=dgdegra@tycho.nsa.gov \
    --cc=konrad.wilk@oracle.com \
    --cc=szhang@research.ait.ie \
    --cc=xen-devel@lists.xen.org \
    /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).