mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
Daniel De Graaf
5ff49ec44b
Because there is not currently a method for the vTPM Manager to obtain a build hash of a vTPM, use the hash of the vTPM's XSM label as a substitute. This allows the vTPM Manager to distinguish between vTPMs intended to be paired with a hardware domain kernel (which cannot use pv-grub) and vTPMs which are paired with a pv-grub domain and therefore contain reliable measurements of the guest kernel in PCRs 4 and 5. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Acked-by: Ian Campbell <ian.campbell@citrix.com>
142 lines
6.5 KiB
Plaintext
142 lines
6.5 KiB
Plaintext
Author: Daniel De Graaf <dgdegra@tycho.nsa.gov>
|
|
|
|
================================================================================
|
|
Overview
|
|
================================================================================
|
|
|
|
This document describes example platforms which use virtual TPMs to provide
|
|
security properties for guests running on the platforms. There are several
|
|
tradeoffs between flexibility and trust which must be considered when
|
|
implementing a platform containing vTPMs.
|
|
|
|
================================================================================
|
|
Example 1: Trusted Domain 0
|
|
================================================================================
|
|
|
|
This is the simplest example and provides maximal flexibility for testing the
|
|
vTPM Manager and vTPMs. The vtpmmgr, vtpm, and guest domains are created using
|
|
xl from the command line on domain 0.
|
|
|
|
Provisioning on domain 0:
|
|
# dd if=/dev/zero of=/images/vtpmmgr-stubdom.img bs=2M count=1
|
|
# dd if=/dev/zero of=/images/vtpm-guest1.img bs=2M count=1
|
|
# dd if=/dev/zero of=/images/vtpm-guest2.img bs=2M count=1
|
|
|
|
The vtpmmgr configuration file (vtpmmgr.cfg):
|
|
|
|
name="vtpmmgr"
|
|
kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
|
|
extra="tpmlocality=2"
|
|
memory=8
|
|
disk=["file:/images/vtpmmgr-stubdom.img,hda,w"]
|
|
iomem=["fed42,1"]
|
|
|
|
The vtpm configuration files (vtpm-guest1.cfg, vtpm-guest2.cfg):
|
|
|
|
name="vtpm-guest1"
|
|
kernel="/usr/lib/xen/boot/vtpm-stubdom.gz"
|
|
extra="loglevel=debug"
|
|
memory=8
|
|
disk=["file:/images/vtpm-guest1.img,hda,w"]
|
|
vtpm=["backend=vtpmmgr,uuid=ac0a5b9e-cbe2-4c07-b43b-1d69e46fb839"]
|
|
|
|
name="vtpm-guest2"
|
|
kernel="/usr/lib/xen/boot/vtpm-stubdom.gz"
|
|
extra="loglevel=debug"
|
|
memory=8
|
|
disk=["file:/images/vtpm-guest2.img,hda,w"]
|
|
vtpm=["backend=vtpmmgr,uuid=6c3ff5f1-8d58-4fed-b00d-a5ea9a817f7f"]
|
|
|
|
The guest configuration files (guest1.cfg, guest2.cfg):
|
|
|
|
name="guest1"
|
|
kernel="/usr/lib/xen/boot/pv-grub-x86_64.gz"
|
|
memory=1024
|
|
disk=["file:/images/guest1.img,xvda,w"]
|
|
vif=['mac=00:01:02:03:04:05,bridge=br0']
|
|
vtpm=["backend=vtpm-guest1"]
|
|
|
|
name="guest2"
|
|
kernel="/usr/lib/xen/boot/pv-grub-x86_64.gz"
|
|
memory=1024
|
|
disk=["file:/images/guest2.img,xvda,w"]
|
|
vif=['mac=00:01:02:03:04:06,bridge=br0']
|
|
vtpm=["backend=vtpm-guest2"]
|
|
|
|
Starting domains:
|
|
|
|
# xl create vtpmmgr.cfg
|
|
# xl create vtpm-guest1.cfg
|
|
# xl create guest1.cfg
|
|
|
|
================================================================================
|
|
Example 2: Domain Builder with Static vTPMs
|
|
================================================================================
|
|
|
|
This example uses the domain builder to construct a TPM Manager and vTPM which
|
|
do not require trusting the hardware domain with the vTPM's secrets. However,
|
|
it is not possible to construct additional vTPMs after the system is booted, and
|
|
the guests with access to vTPMs may not be rebooted without rebooting the entire
|
|
platform.
|
|
|
|
The domain builder (dom0) constructs:
|
|
dom1 - xenstore system_u:system_r:xenstore_t
|
|
dom2 - hardware system_u:system_r:hwdom_t
|
|
dom3 - vtpmmgr system_u:system_r:vtpmmgr_t
|
|
dom4 - vtpm-hw system_u:system_r:vtpm_t
|
|
dom5 - vtpm-g1 guest1_u:vm_r:vtpm_t
|
|
dom6 - vtpm-g2 guest2_u:vm_r:vtpm_t
|
|
dom7 - guest1 guest1_u:vm_r:guest_t
|
|
dom8 - guest2 guest2_u:vm_r:guest_t
|
|
|
|
It unpauses dom1 and dom2 after setting up Xenstore. The hardware domain is not
|
|
permitted access to IO memory at 0xfed42; this IO memory is accessible to the
|
|
vtpmmgr domain. The two guest domains may be instantiated using pv-grub or
|
|
using the same kernel as the hardware domain to conserve space in the domain
|
|
builder's initrd.
|
|
|
|
Once the hardware domain boots, it runs:
|
|
|
|
# xl block-attach vtpmmgr 'backendtype=phy,backend=hardware,vdev=hda,access=w,target=/dev/lvm/vtpmmgr'
|
|
# xl block-attach vtpm-hw 'backendtype=phy,backend=hardware,vdev=hda,access=w,target=/dev/lvm/vtpm-hw'
|
|
# xl block-attach vtpm-g1 'backendtype=phy,backend=hardware,vdev=hda,access=w,target=/dev/lvm/vtpm-g1'
|
|
# xl block-attach vtpm-g2 'backendtype=phy,backend=hardware,vdev=hda,access=w,target=/dev/lvm/vtpm-g2'
|
|
# xl block-attach guest1 'backendtype=phy,backend=hardware,vdev=xvda,access=w,target=/dev/lvm/guest1'
|
|
# xl block-attach guest2 'backendtype=phy,backend=hardware,vdev=xvda,access=w,target=/dev/lvm/guest2'
|
|
# xl vtpm-attach vtpm-hw uuid=062b6416-ed46-492a-9e65-a2f92dc07f7f backend=vtpmmgr
|
|
# xl vtpm-attach vtpm-g1 uuid=e9aa9d0f-ece5-4b84-b129-93004ba61a5f backend=vtpmmgr
|
|
# xl vtpm-attach vtpm-g2 uuid=3fb2caf0-d305-4516-96c7-420618d98efb backend=vtpmmgr
|
|
# xl vtpm-attach hardware uuid=062b6416-ed46-492a-9e65-a2f92dc07f7f backend=vtpm-hw
|
|
# xl vtpm-attach guest1 uuid=e9aa9d0f-ece5-4b84-b129-93004ba61a5f backend=vtpm-g1
|
|
# xl vtpm-attach guest2 uuid=3fb2caf0-d305-4516-96c7-420618d98efb backend=vtpm-g2
|
|
|
|
Once these commands are complete, the domains are unpaused and may boot. The XSM
|
|
policy must be configured to not allow any of the domain types named above to be
|
|
created by any domain except the domain builder; guests created by the hardware
|
|
domain or one of the primary guests acting as a control domain must have a
|
|
different type. The type vtpmmgr_t may only map grants from vtpm_t; vtpm_t may
|
|
only map grants from a domain of type guest_t or hwdom_t with the same user
|
|
field.
|
|
|
|
This example may be extended to allow dynamic creation of domains by using a
|
|
domain builder that accepts build requests. A single build request would create
|
|
a pair of domains using an unused XSM user field: a vTPM and a pv-grub domain
|
|
which requires the presence of a vTPM. To bind the configuration of the guest
|
|
to the vTPM, the guest may use full-disk encryption which can be unlocked using
|
|
an unseal operation; using the wrong vTPM will then yield a non-functioning
|
|
guest.
|
|
|
|
In order to use pv-grub to obtain measurements of the guest kernel in PCRs 4 and
|
|
5, it must not be possible to attach to a guest's vTPM without booting a fresh
|
|
guest image. This requires pairing every vTPM's launch with the launch of a
|
|
guest, as described above, and using the --vtpm-label= argument to pv-grub so
|
|
that it refuses to launch a guest if it could not write to the vTPM. To permit
|
|
the hardware domain, which cannot use pv-grub, to use a vTPM in this situation,
|
|
multiple vTPM groups must be used in the TPM Manager. Group 0 would be for the
|
|
hardware domain only, and would only support vTPMs with label
|
|
"system_u:system_r:vtpm_t". Group 1 would support vTPMs with label
|
|
"*:vm_r:vtpm_t", and would be used for all guest vTPMs. The EK quote used in
|
|
initial provisioning and any deep quotes produced later would include the label,
|
|
which would allow a verifier to reliably determine if the value of the vTPM's
|
|
PCR 4 contains the hash of the domain's kernel.
|