[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Architecture for dom0 integrity measurements.

On 01/12/2015 10:53 AM, Xu, Quan wrote:
Hi, Dr. G.W. Wettstein

cc Graaf who is vTPM / XSM maintainer.
Also cc Stefano.

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Dr. Greg Wettstein
Sent: Saturday, January 10, 2015 10:59 PM
To: xen-devel@xxxxxxxxxxxxx
Subject: [Xen-devel] Architecture for dom0 integrity measurements.

Hi, I hope the weekend is going well for everyone.

We have been watching the discussions on the list over the holiday on the
refinement and enhancement of the TPM architecture for Xen, including
support for TPM 2.0.  We are active in measured platform development and I
wanted to pose what is perhaps a philosophical question to everyone.

Our systems boot from a hardware root of trust via TXT and we heavily leverage
the Linux Integrity Measurement Architecture (IMA) for mutual remote

Is it based on TBoot / OpenAttestation ?

I understand the motivation for running the TPM hardware
manager in an IO emulation domain but unless I miss something in the current
discussions, this architecture precludes the ability of the dom0 kernel to
physically access the TPM which in turn prevents
dom0 from implementing a hardware referenced measurement state via IMA.

Graaf can answer it.

Ideally, domain 0 would use its own vTPM to record IMA measurements.
However, it is not currently possible to use IMA with a vTPM that is
started after the domain 0 kernel has booted.  In addition, the current
vTPM emulator requires working disk I/O and a working vTPM Manager
domain before it will accept commands.

Architecture 1:

Domain 0 boots with access to the physical TPM (via tpm_tis) and uses it
to store IMA measurements.  During boot, the vTPM Manager domain and a
vTPM for domain 0 are started.  Since the vTPM Manager currently uses
locality 2 while Linux uses locality 0, concurrent access is possible
without needing a cross-domain lock.  The TPM driver in both minios and
Linux will wait long enough for a short command (such as a PCR extend)
to complete when submitting their commands.

Once the vTPM has been started, the physical TPM can be hot-unplugged
from domain 0, causing future TPM commands to be directed to the vTPM.
The vTPM for domain 0 should be configured to mirror hardware PCRs on
startup so that the early IMA measurements are reflected in the vTPM.

One problem with this: the process of switching from physical to
virtual TPM needs to happen during a quiescent period for IMA
measurements.  This will result in the vTPM's PCR10 containing the full
IMA log and the pTPM's PCR10 containing an earlier, truncated version.
If IMA events happen during the switch, there will be some measurements
only present in the hardware TPM with the remaining only be present in
the vTPM.  While it is possible to reconstruct the values of each PCR
during verification, this is more complex and should be avoided if
possible.  In either case, a verifier should check both physical and
virtual TPM's PCR10 values for validity against the dom0 IMA log.

Architecture 2:

A more disaggregated system can use a domain 0 that uses no permanent
state: its root filesystem would be a ramdisk optionally supplemented
with a dm-verity disk image.  This type of domain does not need to use
IMA, and so can avoid any TPM access until both the vTPM Manager and
vTPMs are created.  Normal domain 0 functions would actually be
performed by a toolstack domain distinct from domain 0.

This is the architecture that I have primarily used in testing.

Architecture 3 (requires changes to the vTPM domain):

A domain builder (stub domain) creates an initial set of domains
including Xenstore, vTPM Manager, hardware domain, and a vTPM for the
hardware domain.  The vTPM must be capable of performing PCR extend
operations and other commands prior to being able to access its disk
image, which will be attached (xl block-attach) during the hardware
domain's boot process.

Boot event order here:
 1. Xen startup (pre-dom0)
 2. Domain builder starts as dom0
 3. Creation of xenstore, vtpmmgr, vtpm-hwdom, hwdom
 4. Wire up vTPM connection for hwdom in Xenstore
 5. Unpause vtpm-hwdom and hwdom
 6. Hardware domain boots, uses vtpm-hwdom for IMA logging
 7. Disk images for vtpmmgr and vtpm-hwdom attached
 8. Unpause vtpmmgr domain
 9. Start trousers and/or use kernel trusted-keys operations

Others may disagree but I wouldn't even contemplate delivering an integrity
certified platform without including all of the dom0 infrastructure into the
platform measurement status.  We heavily leverage the current 4.4.x vTPM
implementation for testing and development and the documentation states
clearly to not integrate TPM/TIS support into the dom0 OS.


Right, measuring domain 0 is important in getting useful assurance from a
platform.  Using other TPM functionality within domain 0 may also be useful,
which is why I think making a vTPM available to domain 0 is a good solution.
The recommendation in the documents is really about access to the physical
TPM, which interferes with the vtpmmgr domain.

The obvious model is to run a software TPM simulator in dom0 and have the
vTPM I/O domains link to that.  We are heavily invested in IBM's software TPM
simulator and have been tossing around the idea of building up a proof of
concept based on that.  I wanted to make sure we were not misunderstanding
anything with the current or proposed architecture before we invest the

IBM's software TPM simulator, is it libtpms?
For all I know, the libtpms is a library that targets the integration of TPM 
functionality into hypervisors.
In this mode, libtpms is dynamic linking library, so there is no root of trust.
If you really want to enable it, I have some

1. vTPM I/O domains is now needed in this mode, QEMU can implement another TPM
Backend to link libtpms. Try to refer to

2. Enabling seabios for HVM virtual machine.
Refer to patch ' vTPM: add TPM TCPA and SSDT for HVM virtual machine'
And https://github.com/virt2x/seabios2

Using libtpms does not prevent having a root of trust, but it does
greatly increase the size of the required trusted computing base to
include all the software with sufficient privilege in domain 0 (and
relevant configurations).  This can be measured by a properly configured
IMA policy, although it is more difficult to perform local attestation
with IMA (the exact ordering of IMA records is often not deterministic,
meaning you cannot reasonably seal secrets to a state that includes the

One of the features of Xen's vTPM architecture is that it is possible to
have a domU that trusts as little of domain 0 as possible.  With a domain
builder to bootstrap the domU into a trusted state, this does not need to
include any management software or even the hardware domain's kernel.
However, this level of independence is not useful to most guests because
it requires that a guest perform its own disk/network encryption, which
conflicts with useful features such as cloning a guest.  Migration also
becomes more complex (requiring a separate migration domain).

- Daniel

We have also been considering whether or not to implement the multiple TPM
states in the context of the dom0 hardware virtualization instance.

Does it mean initial states from libtpms? Such as clear/save/.etc. Correct me, 
if I am wrong..

again not as 'technically secure' but it does cut out a lot of complexity with 
current model,

Yes, agree with this point.

with the added benefit of that infrastructure being covered by a
hardware rooted IMA state.

Also we are extremely interested in what hardware and motherboards with TPM
2.0 support are being used for this development, obviously with TXT being a
requirement.  It wasn't too long ago we were advised directly by Intel that
physical hardware was not available, perhaps that was a miscommunication.
Given the work being done, and the Intel e-mail addresses on the patches, there
is obviously access to 2.0 compliant hardware or is all this being done with

NOT simulator, it is on TPM 2.0 hardware.
The attach file is the output of ' dmidecode' on physical machine with TPM 2.0.
These 2 machine are from Huawei/Nationz. I can ask them for more information.


Thanks for any reflections the group may have.

Best wishes for a productive week.


As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@xxxxxxxxxxxx
"Against stupidity the Gods themselves contend in vain."
                                 -- Freidrich von Schiller

Xen-devel mailing list

Daniel De Graaf
National Security Agency

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.