Re: [Xen-devel] [PATCH v3 00/14] Enable vTPM subsystem on TPM 2.0

["Xu, Quan" <quan.xu@xxxxxxxxx>]

Graaf,
Now there are no more comments for this series of patch. 
Can this series of patch be merged in staging branch? or any other AR, let me 
know. 
If the series of patch are in staging branch, the Community and I can continue 
to develop and enhance it.


Thanks 
Quan

> -----Original Message-----
> From: Xu, Quan
> Sent: Wednesday, December 31, 2014 1:50 PM
> To: xen-devel@xxxxxxxxxxxxx
> Cc: dgdegra@xxxxxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx;
> samuel.thibault@xxxxxxxxxxxx; ian.campbell@xxxxxxxxxx;
> ian.jackson@xxxxxxxxxxxxx; jbeulich@xxxxxxxx; keir@xxxxxxx; tim@xxxxxxx; Xu,
> Quan
> Subject: [PATCH v3 00/14] Enable vTPM subsystem on TPM 2.0
> 
> ###################
> # Happy New Year..#
> ###################
> 
> This series of patch enable the virtual Trusted Platform Module (vTPM)
> subsystem for Xen on TPM 2.0.
> 
> Noted, functionality for a virtual guest operating system (a DomU) is still 
> TPM
> 1.2. The main modifcation is on vtpmmgr-stubdom. The challenge is that TPM
> 2.0 is not backward compatible with TPM 1.2.
> 
> ------------------------------
> DESIGN OVERVIEW
> ------------------------------
> The architecture of vTPM subsystem on TPM 2.0 is described below:
> 
> +------------------+
> |    Linux DomU    | ...
> |       |  ^       |
> |       v  |       |
> |   xen-tpmfront   |
> +------------------+
>         |  ^
>         v  |
> +------------------+
> | mini-os/tpmback  |
> |       |  ^       |
> |       v  |       |
> |  vtpm-stubdom    | ...
> |       |  ^       |
> |       v  |       |
> | mini-os/tpmfront |
> +------------------+
>         |  ^
>         v  |
> +------------------+
> | mini-os/tpmback  |
> |       |  ^       |
> |       v  |       |
> | vtpmmgr-stubdom  |
> |       |  ^       |
> |       v  |       |
> | mini-os/tpm2_tis |
> +------------------+
>         |  ^
>         v  |
> +------------------+
> | Hardware TPM 2.0 |
> +------------------+
>  * Linux DomU: The Linux based guest that wants to use a vTPM. There many
> be
>                more than one of these.
> 
>  * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver
>                     provides vTPM access to a para-virtualized Linux based
> DomU.
> 
>  * mini-os/tpmback: Mini-os TPM backend driver. The Linux frontend driver
>                     connects to this backend driver to facilitate
>                     communications between the Linux DomU and its
> vTPM. This
>                     driver is also used by vtpmmgr-stubdom to
> communicate with
>                     vtpm-stubdom.
> 
>  * vtpm-stubdom: A mini-os stub domain that implements a vTPM. There is a
>                  one to one mapping between running vtpm-stubdom
> instances and
>                  logical vtpms on the system. The vTPM Platform
> Configuration
>                  Registers (PCRs) are all initialized to zero.
> 
>  * mini-os/tpmfront: Mini-os TPM frontend driver. The vTPM mini-os domain
>                      vtpm-stubdom uses this driver to communicate with
>                      vtpmmgr-stubdom. This driver could also be used
> separately to
>                      implement a mini-os domain that wishes to use a
> vTPM of
>                      its own.
>  * vtpmmgr-stubdom: A mini-os domain that implements the vTPM manager.
>                There is only one vTPM manager and it should be running
> during
>                the entire lifetime of the machine.  This domain regulates
>                access to the physical TPM on the system and secures the
>                persistent state of each vTPM.
> 
>  * mini-os/tpm2_tis: Mini-os TPM version 2.0 TPM Interface Specification (TIS)
>                     driver. This driver used by vtpmmgr-stubdom to talk
> directly
>                     to the hardware TPM 2.0. Communication is facilitated
> by mapping
>                     hardware memory pages into vtpmmgr-stubdom.
> 
>  * Hardware TPM 2.0: The physical TPM 2.0 that is soldered onto the
> motherboard.
> 
> 
> ------------------------------
> Key Hierarchy
> ------------------------------
> 
>     +------------------+
>     |  vTPM's secrets  | ...
>     +------------------+
>             |  ^
>             |  |(Bind / Unbind)
> - - - - -  -v  |- - - - - - - - TPM 2.0
>     +------------------+
>     |        SK        +
>     +------------------+
>             |  ^
>             v  |
>     +------------------+
>     |       SRK        |
>     +------------------+
>             |  ^
>             v  |
>     +------------------+
>     | TPM 2.0 Storage  |
>     |   Primary Seed   |
>     +------------------+
> ------------------------------
> INSTALLATION
> ------------------------------
> 
> Prerequisites:
> --------------
> You must have an x86 machine with a TPM on the motherboard.  The only
> extra software requirement for compiling vTPM is cmake.  You must use libxl
> to manage domains with vTPMs; 'xm' is deprecated and does not support
> vTPMs.
> 
> Compiling the Xen tree:
> -----------------------
> 
> Compile and install the Xen tree as usual; be sure that the vTPM domains are
> enabled when you run configure.
> 
> Compiling the LINUX dom0 kernel:
> --------------------------------
> 
> Because the TPM manager uses direct access to the physical TPM, it may
> interfere with access to the TPM by dom0.  The simplest solution for this is 
> to
> prevent
> dom0 from accessing the physical TPM by compiling the kernel without a driver
> or blacklisting the module.
> 
> Compiling the LINUX domU kernel:
> --------------------------------
> 
> The domU kernel used by domains with vtpms must include the xen-tpmfront.ko
> driver. It can be built directly into the kernel or as a module; however, some
> features such as IMA require the TPM to be built in to the kernel.
> 
> 
> CONFIG_TCG_TPM=y
> CONFIG_TCG_XEN=y
> 
> ------------------------------
> VTPM MANAGER SETUP
> ------------------------------
> 
> Manager disk image setup:
> -------------------------
> 
> The vTPM Manager requires a disk image to store its encrypted data. The image
> does not require a filesystem and can live anywhere on the host disk. The 
> image
> is not large; the Xen 4.5 vtpmmgr is limited to using the first 2MB of the 
> image
> but can support more than 20,000 vTPMs.
> 
>  dd if=/dev/zero of=/home/vtpm2/vmgr bs=16M count=1
> 
> Manager config file:
> --------------------
> 
> The vTPM Manager domain (vtpmmgr-stubdom) must be started like any other
> Xen virtual machine and requires a config file.  The manager requires a disk
> image for storage and permission to access the hardware memory pages for
> the TPM. The disk must be presented as "hda", and the TPM memory pages are
> passed using the iomem configuration parameter. The TPM TIS uses 5 pages of
> IO memory (one per
> locality) that start at physical address 0xfed40000. By default, the TPM 
> manager
> uses locality 0 (so only the page at 0xfed40 is needed).
> 
> Add:
> ..
>      extra="tpm2"
> ..
> extra option to launch vtpmmgr-stubdom domain on TPM 2.0, and ignore it on
> TPM 1.x. for example:
> 
>     kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
>     memory=128
>     disk=["file:/home/vtpm2/vmgr,hda,w"]
>     name="vtpmmgr"
>     iomem=["fed40,5"]
>     extra="tpm2"
> 
> ------------------------------
> VTPM AND LINUX PVM SETUP
> ------------------------------
> vTPM disk image setup:
> ----------------------
> 
> The vTPM requires a disk image to store its persistent data (RSA keys, NVRAM,
> etc). The image does not require a filesystem. The image does not need to be
> large; 2 Mb should be sufficient.
> 
>     dd if=/dev/zero of=/home/vtpm2/vtpm0 bs=2M count=1
> 
> vTPM config file:
> -----------------
> 
> The vTPM domain requires a configuration file like any other domain. The vTPM
> requires a disk image for storage and a TPM frontend driver to communicate
> with the manager.  You are required to generate a uuid for this vtpm, which is
> specified on the "vtpm=" line that describes its connection to the vTPM
> Manager.
> for example:
> 
>     kernel="/usr/lib/xen/boot/vtpm-stubdom.gz"
>     memory=8
>     disk=["file:/home/vtpm2/vtpm0,hda,w"]
>     name="vtpm0"
> 
> vtpm=["backend=vtpmmgr,uuid=914fe389-e2c5-44e6-993f-2189637cf1de"]
> 
> If you wish to clear the vTPM data you can either recreate the disk image or
> change the uuid.
> 
> Linux Guest config file:
> ------------------------
> The Linux guest config file needs to be modified to include the Linux tpmfront
> driver. Add the following line:
> 
> vtpm=["backend=vtpm0"]
> 
> Currently only Linux guests are supported (PV or HVM with PV drivers). My 
> series
> of patch for HVM virtual mahcine are still being reviewed and modifcated.
> 
> Using the vTPM in the guest:
> ----------------------------
> 
> If xen-tpmfront was compiled as a module, it must be loaded it in the guest.
> 
> # modprobe xen-tpmfront
> 
> After the Linux domain boots and the xen-tpmfront driver is loaded, you should
> see the following on the vtpm console:
> 
> Info: VTPM attached to Frontend X/Y
> 
> You can quickly test the vTPM by using the sysfs interface:
> # cat /sys/devices/vtpm-0/pubek
> # cat /sys/devices/vtpm-0/pcrs
> If you have trousers and tpm_tools installed on the guest, the tpm_version
> command should return the following:
> 
> The version command should return the following:
>   TPM 1.2 Version Info:
>   Chip Version:        1.2.0.7
>   Spec Level:          2
>   Errata Revision:     1
>   TPM Vendor ID:       ETHZ
>   TPM Version:         01010000
>   Manufacturer Info:   4554485a
> 
> You should also see the command being sent to the vtpm console as well as the
> vtpm saving its state. You should see the vtpm key being encrypted and stored
> on the vtpmmgr console.
> 
> You may wish to write a script to start your vtpm and guest together and to
> destroy the vtpm when the guest shuts down.
> ------------------------------
> INTEGRATION WITH PV-GRUB
> ------------------------------
> 
> The vTPM currently starts up with all PCRs set to their default values (all 
> zeros
> for the lower 16).  This means that any decisions about the trustworthiness of
> the created domain must be made based on the environment that created the
> vTPM and the domU; for example, a system that only constructs images using a
> trusted configuration and guest kernel be able to provide guarantees about the
> guests and any measurements done that kernel (such as the IMA TCB log).
> Guests wishing to use a custom kernel in such a secure environment are often
> started using the pv-grub bootloader as the kernel, which then can load the
> untrusted kernel without needing to parse an untrusted filesystem and kernel 
> in
> dom0.  If the pv-grub stub domain succeeds in connecting to a vTPM, it will
> extend the hash of the kernel that it boots into PCR #4, and will extend the
> command line and initrd into PCR #5 before booting so that a domU booted in
> this way can attest to its early boot state.
> 
> ------------------------------
> REFERENCES
> ------------------------------
> 
> Berlios TPM Emulator:
> http://tpm-emulator.berlios.de/
> Xen docs/misc/vtpm.txt
> Xen docs/misc/vtpm-platforms.txt
> Xen docs/misc/vtpmmgr.txt
> 
> --Changes in V3:
>   1. Add 'olen' parameter in 'stubdom/vtpmmgr/disk_read.c', which is lost in
> v2.
> 
> --Changes in V2:
>   1. Record some infomation in docs/misc/vtpmmgr.txt.
>   2. Add TPM 2.0 PCRs read.
>   3. Bind/Unbind the measurements of the hypervisor and other
>      TCB components.
>   4. Change extra option from '--tpm2' to 'tpm2'
> 
> Quan Xu (14):
>   vTPM/TPM2: Add TPM 2.0 data structures and commands definition
>   vTPM/TPM2: TPM 2.0 data structures marshal
>   vTPM/TPM2: Add global data in vtpm_globals{}
>   vTPM/TPM2: Add TPM 2.0 Exposed APIs
>   vTPM/TPM2: TPM 2.0 takes ownership and create SRK
>   vTPM/TPM2: Create and load SK on TPM 2.0
>   vTPM/TPM2: TPM2.0 TIS initialization and self test.
>   vTPM/TPM2: Add main entrance vtpmmgr2_init()
>   vTPM/TPM2: Support 'tpm2' extra command line.
>   vTPM/TPM2: TPM 2.0 PCRs read
>   vTPM/TPM2: Support TPM 2.0 bind and unbind data
>   vTPM/TPM2: Bind group keys and sectors data on disk
>   vTPM/TPM2: Unind group keys and sectors data on disk
>   vTPM/TPM2: Record some infomation in docs/misc/vtpmmgr.txt about
> 
>  docs/misc/vtpmmgr.txt            | 150 +++++-
>  extras/mini-os/include/tpm_tis.h |   1 +
>  extras/mini-os/tpm_tis.c         | 156 +++++++
>  stubdom/vtpmmgr/Makefile         |   2 +-
>  stubdom/vtpmmgr/disk_read.c      |  17 +-
>  stubdom/vtpmmgr/disk_tpm.c       |  42 +-
>  stubdom/vtpmmgr/disk_tpm.h       |   4 +
>  stubdom/vtpmmgr/disk_write.c     |  13 +-
>  stubdom/vtpmmgr/init.c           | 315 +++++++++++++
>  stubdom/vtpmmgr/tpm2.c           | 455 ++++++++++++++++++
>  stubdom/vtpmmgr/tpm2.h           | 104 +++++
>  stubdom/vtpmmgr/tpm2_marshal.h   | 673
> +++++++++++++++++++++++++++
>  stubdom/vtpmmgr/tpm2_types.h     | 980
> +++++++++++++++++++++++++++++++++++++++
>  stubdom/vtpmmgr/vtpmmgr.c        |  46 +-
>  stubdom/vtpmmgr/vtpmmgr.h        |  29 ++
>  15 files changed, 2973 insertions(+), 14 deletions(-)  create mode 100644
> stubdom/vtpmmgr/tpm2.c  create mode 100644 stubdom/vtpmmgr/tpm2.h
> create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h  create mode
> 100644 stubdom/vtpmmgr/tpm2_types.h
> 
> --
> 1.8.3.2

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel