[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 00/14] Enable vTPM subsystem on TPM 2.0
> -----Original Message----- > From: Daniel De Graaf [mailto:dgdegra@xxxxxxxxxxxxx] > Sent: Tuesday, January 13, 2015 11:54 PM > To: Xu, Quan; xen-devel@xxxxxxxxxxxxx > Cc: stefano.stabellini@xxxxxxxxxxxxx; samuel.thibault@xxxxxxxxxxxx; > ian.campbell@xxxxxxxxxx; ian.jackson@xxxxxxxxxxxxx; jbeulich@xxxxxxxx; > keir@xxxxxxx; tim@xxxxxxx > Subject: Re: [PATCH v3 00/14] Enable vTPM subsystem on TPM 2.0 > > On 01/12/2015 11:06 AM, Xu, Quan wrote: > > 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. > > A few remaining comments: > > Patch 6 adds an #if 0 block; is this test code that you meant to remove? > Thanks, It is just an example how to bind/unbind. I will remove it in v4 and send out v4 ASAP. > Patch 9 (see reply). > I will fix it. > Are you planning to replace TPM2_Bind with TPM2_Seal in a later series? > If so, please make a note of this limitation in the documentation for TPM2, > since > using PCRs to seal the data can be an important security feature that users > of the > vtpmmgr rely on. Yes, I will replace TPM2_Bind with TPM2_Seal in a later series. > > For the other patches in this series (1-5,7-8,10): > Acked-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> > > With patch #14 documenting the lack of TPM2 sealing, #11-13 are also Acked. > I will fix the Patch#14 documenting the lack of TPM2 sealing in v4. Thanks again. Quan > - Daniel > > > > > 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 > > > > > > > -- > Daniel De Graaf > National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |