Thanks to Vinnie for getting into more background on why the vTPM
Manager isn't using a gneral TSS. This fills-in the background on my
previous answer to this same question:
http://lists.xensource.com/archives/html/xen-devel/2007-07/msg00812.html
.
In your (Luke's) original reply to this, you stated that you wanted to:
My goal is to be able to do all of the following, though no two
need to occur simultaneously
1) Run vtpm_managerd
2) create tpm keys in the dom0
3) create vtpm keys in the domu
and then later that you had gotten 1) and 3) working.
As Vinnie explained, if you have a need for a somewhat privileged domain
to use keys, it would be preferable to do that within a secure domU.
It has long been a goal of the Xen security community to disaggregate
dom0, and in such a case, the vTPM Manager would most likely end up in a
small domain to itself. So a forward-looking design would be to use a
secure domU for any TPM operations.
Is your intended use something that cannot work in such a model and
requires access to the hardware TPM?
Joe
________________________________
From: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xense-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Scarlata,
Vincent R
Sent: Thursday, September 20, 2007 8:08 PM
To: Luke; Xense-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xense-devel] vtpm_managerd locks the TPM
Due to the TPM's interface, only one application can access the
TPM at a time, so "locking" is somewhat implicit. In a general purpose
OS, it is the expectation of TCG that the single application that uses
the TPM is the system service implementing the TPM Software Stack (TSS)
(ie trousers). Many applications can then use RPCs to communicate with
the TSS, which multiplexes their requests to the TPM.
That said, TPM virtualization is a very security sensitive
operation that is meant to be done in a static minimalist environment.
This is because any root exploit in the domain housing the vTPM
processes would yield a compromise in vTPM keys. It's not expected that
a full TSS, other TPM apps, or any user apps will be running along side
the vTPM manager. For example, an ideal configuration would be to put
the vTPM manager & vTPMs in a dedicated domain. An alternative would be
a to run it in a very stripped down, static, Dom0 that runs off an
initrd. In both these configurations, the vTPM manager should talk
directly to the TPM driver rather than require the inclusion of a TSS
service.
If you do want to run the vTPM manager in a more general purpose
Dom0 that has other TPM applications, you would need a new vtsp.c file
that calls trousers rather than the internal stack to the TPM driver.
-Vinnie Scarlata
________________________________
From: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xense-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Luke
Sent: Thursday, September 20, 2007 10:45 PM
To: Xense-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xense-devel] vtpm_managerd locks the TPM
It seems like vtpm_managerd locks the TPM when I try to use it.
I can't run bindfile/unbindfile commands, do a tpm_demo, etc
when vtpm_managerd is running. I get I/O errors or get_capability
errors (using the old IBM TPM command suite), which seems to suggest
that vtpm_managerd locks the TPM from other commands.
Have other people found this to be the case as well? Is there
any fix for this? Why does vtpm_managerd need to lock the TPM?
Anyone try Trousers with vtpm_manager simultaneously?
Thanks for the help -
--
Luke
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel
|
Home