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
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
|