1Virtual TPM interface for Xen 2 3Authors: Matthew Fioravante (JHUAPL), Daniel De Graaf (NSA) 4 5This document describes the virtual Trusted Platform Module (vTPM) subsystem for 6Xen. The reader is assumed to have familiarity with building and installing Xen, 7Linux, and a basic understanding of the TPM and vTPM concepts. 8 9INTRODUCTION 10 11The goal of this work is to provide a TPM functionality to a virtual guest 12operating system (in Xen terms, a DomU). This allows programs to interact with 13a TPM in a virtual system the same way they interact with a TPM on the physical 14system. Each guest gets its own unique, emulated, software TPM. However, each 15of the vTPM's secrets (Keys, NVRAM, etc) are managed by a vTPM Manager domain, 16which seals the secrets to the Physical TPM. If the process of creating each of 17these domains (manager, vTPM, and guest) is trusted, the vTPM subsystem extends 18the chain of trust rooted in the hardware TPM to virtual machines in Xen. Each 19major component of vTPM is implemented as a separate domain, providing secure 20separation guaranteed by the hypervisor. The vTPM domains are implemented in 21mini-os to reduce memory and processor overhead. 22 23This mini-os vTPM subsystem was built on top of the previous vTPM work done by 24IBM and Intel corporation. 25 26 27DESIGN OVERVIEW 28--------------- 29 30The architecture of vTPM is described below: 31 32+------------------+ 33| Linux DomU | ... 34| | ^ | 35| v | | 36| xen-tpmfront | 37+------------------+ 38 | ^ 39 v | 40+------------------+ 41| mini-os/tpmback | 42| | ^ | 43| v | | 44| vtpm-stubdom | ... 45| | ^ | 46| v | | 47| mini-os/tpmfront | 48+------------------+ 49 | ^ 50 v | 51+------------------+ 52| mini-os/tpmback | 53| | ^ | 54| v | | 55| vtpmmgr-stubdom | 56| | ^ | 57| v | | 58| mini-os/tpm_tis | 59+------------------+ 60 | ^ 61 v | 62+------------------+ 63| Hardware TPM | 64+------------------+ 65 66 * Linux DomU: The Linux based guest that wants to use a vTPM. There may be 67 more than one of these. 68 69 * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver 70 provides vTPM access to a Linux-based DomU. 71 72 * mini-os/tpmback: Mini-os TPM backend driver. The Linux frontend driver 73 connects to this backend driver to facilitate communications 74 between the Linux DomU and its vTPM. This driver is also 75 used by vtpmmgr-stubdom to communicate with vtpm-stubdom. 76 77 * vtpm-stubdom: A mini-os stub domain that implements a vTPM. There is a 78 one to one mapping between running vtpm-stubdom instances and 79 logical vtpms on the system. The vTPM Platform Configuration 80 Registers (PCRs) are normally all initialized to zero. 81 82 * mini-os/tpmfront: Mini-os TPM frontend driver. The vTPM mini-os domain 83 vtpm-stubdom uses this driver to communicate with 84 vtpmmgr-stubdom. This driver is also used in mini-os 85 domains such as pv-grub that talk to the vTPM domain. 86 87 * vtpmmgr-stubdom: A mini-os domain that implements the vTPM manager. There is 88 only one vTPM manager and it should be running during the 89 entire lifetime of the machine. This domain regulates 90 access to the physical TPM on the system and secures the 91 persistent state of each vTPM. 92 93 * mini-os/tpm_tis: Mini-os TPM version 1.2 TPM Interface Specification (TIS) 94 driver. This driver used by vtpmmgr-stubdom to talk directly to 95 the hardware TPM. Communication is facilitated by mapping 96 hardware memory pages into vtpmmgr-stubdom. 97 98 * Hardware TPM: The physical TPM that is soldered onto the motherboard. 99 100 101INTEGRATION WITH XEN 102-------------------- 103 104Support for the vTPM driver was added in Xen using the libxl toolstack in Xen 1054.3. See the Xen documentation (docs/misc/vtpm.txt) for details on setting up 106the vTPM and vTPM Manager stub domains. Once the stub domains are running, a 107vTPM device is set up in the same manner as a disk or network device in the 108domain's configuration file. 109 110In order to use features such as IMA that require a TPM to be loaded prior to 111the initrd, the xen-tpmfront driver must be compiled in to the kernel. If not 112using such features, the driver can be compiled as a module and will be loaded 113as usual. 114