Re: Questions about the usage of the vTPM implemented in Xen 4.3

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 02/05/2014 11:52 AM, Jordi Cucurull Juan wrote:
> Dear all,
>
> I have recently configured a Xen 4.3 server with the vTPM enabled and a
> guest virtual machine that takes advantage of it. After playing a bit
> with it, I have a few questions:
>
> 1.According to the documentation, to shutdown the vTPM stubdom it is
> only needed to normally shutdown the guest VM. Theoretically, the vTPM
> stubdom automatically shuts down after this. Nevertheless, if I shutdown
> the guest the vTPM stubdom continues active and, moreover, I can start
> the machine again and the values of the vTPM are the last ones there
> were in the previous instance of the guest. Is this normal?

The documentation is in error here; while this was originally how the vTPM
domain behaved, this automatic shutdown was not reliable: it was not done
if the peer domain did not use the vTPM, and it was incorrectly triggered
by pv-grub's use of the vTPM to record guest kernel measurements (which was
the immediate reason for its removal). The solution now is to either send a
shutdown request or simply destroy the vTPM upon guest shutdown.

An alternative that may require less work on your part is to destroy
the vTPM stub domain during a guest's construction, something like:

#!/bin/sh -e
xl destroy "$1-vtpm" || true
xl create $1-vtpm.cfg
xl create $1-domu.cfg

Allowing a vTPM to remain active across a guest restart will cause the
PCR values extended by pv-grub to be incorrect, as you observed in your
second email. In order for the vTPM's PCRs to be useful for quotes or
releasing sealed secrets, you need to ensure that a new vTPM is started
if and only if it is paired with a corresponding guest.

> 2.In the documentation it is recommended to avoid accessing the physical
> TPM from Dom0 at the same time than the vTPM Manager stubdom.
> Nevertheless, I currently have the IMA and the Trousers enabled in Dom0
> without any apparent issue. Why is not recommended directly accessing
> the physical TPM of Dom0?

While most of the time it is not a problem to have two entities talking to
the physical TPM, it is possible for the trousers daemon in dom0 to interfere
with key handles used by the TPM Manager. There are also certain operations
of the TPM that may not handle concurrency, although I do not believe that
trousers uses them - SHA1Start, the DAA commands, and certain audit logs
come to mind.

The other reason why it is recommended to avoid pTPM access from dom0 is
because the ability to send unseal/unbind requests to the physical TPM makes
it possible for applications running in dom0 to decrypt the TPM Manager's
data (and thereby access vTPM private keys).

At present, sharing the physical TPM between dom0 and the TPM Manager is
the only way to get full integrity checks.

> 3.If it is not recommended to directly accessing the physical TPM in
> Dom0, which is the advisable way to check the integrity of this domain?
> With solutions such as TBOOT and IntelTXT?

While the TPM Manager in Xen 4.3/4.4 does not yet have this functionality,
an update which I will be submitting for inclusion in Xen 4.5 has the
ability to get physical TPM quotes using a virtual TPM. Combined with an
early domain builder, the eventual goal is to have dom0 use a vTPM for
its integrity/reporting/sealing operations, and use the physical TPM only
to secure the secrets of vTPMs and for deep quotes to provide fresh proofs
of the system's state.

> Best regards,
> Jordi.

-- 
Daniel De Graaf
National Security Agency