On the third Virtualization Security Podcast of 2011 we were joined by Charlton Barreto of Intel to further discuss the possibility of using TPM/TXT to enhance security within the virtual and cloud environments. We are not there yet, but we discussed in depth the issues with bringing hardware based integrity and confidentiality up further into the virtualized layers of the cloud. TPM and TXT currently provide the following per host security:

  • The Trusted Platform Module (TPM) provides a way to store the checksum of a boot volume to ensure that the boot volume of a host is the proper volume from which to boot. TPM can also store biometric data associated with fingerprint scanners. In essence, TPM stores data for later comparison.
  • The TPM Extensions or TXT, increases the amount of data stored within the TPM to include a checksum associated with the kernel to be booted from the trusted volume.
  • TXT also allows the storage of application checksums to be run ontop of the trusted kernel.

This all means that TXT can ensure that the vmware-vmx application has not been modified, and will be executed by a trusted kernel which also has not been modified which has been launched from a trusted volume. How does this help us with security? In essence, we can have attestation, that what we launched was what we desired to launch all the way through the boot process of a given host. It is a defense against blue-pill attacks as well attacks against critical applications within the environment such as vmware-vmx (which is the object in which a guest operating system runs).

Unfortunately, this attestation stops short of the guest operating system. We cannot currently tell if the guest operating system is really the one we wanted to launch within the VM object, only that the VM object code has not been modifed. These are very important aspects of tying hardware trust to virtual machines. But it currently falls short of where we actually want to be, that is the tying hardware trust all the way through to the application running within the guest operating system which runs within trusted VM object. We have to bring this trust model up at least two more layers.

On top of this, on of the biggest issues with the cloud is jurisdiction of where the data within a VM object lives.  Which geo-location does the VM object reside or can reside. The fear is that a VM object that legally can only live within the EU will end up within the US where different privacy laws apply. To combat this, TXT has one other feature that was demoed at RSA Conference 2011. That feature is a geo-location tag that can be associated within a given TPM/TXT device that resides within each core. Currently, this geo-location tag has to be set by hand, but it could be set via a trusted GPS or network device as well. Once more applying hardware trust to solve an all important problem within the cloud.

There are several issues associated with the current TPM/TXT model:

  • Attestation is done only once, at boot and not continuously. So if someone hacked a running system, the hardware attestation does not reinspect the running VM object (vmware-vmx), or the running kernel, nor the current in use boot volume.
  • Attestation does not currently understand the concept of Live Migration or vMotion of VMs.
  • Attestation does not currently include a VMs configuration file, but only the actual vmware-vmx code.
  • Attestation does not work outside a single host.

In essence, TPM/TXT is currently limited to just the host on which the VM object runs and does not currently understand the myriad of files that actually make up a running VM (just the single binary named vmware-vmx). Nor is there the ability to do continual monitoring of the in memory footprint of the kernel or vmware-vmx binaries to ensure they have not changed. Virtualization hosts are rebooted so infrequently. Yes I can have a trusted launch of a hypervisor, but how can I maintain that the host has not be compromised after the launch? TPM/TXT also does not handle clusters of hosts yet, where VM objects can move around the cluster at will.

Charlton theorized that a separate peer (to a CPU core) device would be required to maintain the TPM/TXT registers across the host by maintaining critical data about each TPM/TXT device that lives within each core of the cluster. This peer device would in essence perform key management out of band from the traditional TPM/TXT trust of the hardware. One such device could be an hardware security module (HSM) used to hold critical certificate data under lock and key. Such a peer device would be crucial to be able to verify virtual machine integrity as it moves around the virtual environment (from host to host).

In addition, such a peer device could be expanded to maintain key information for the encryption of memory by the Intel processors making use of the AES&I instructions that speed up AES based encryption tools.  In essence, keys would not be stored within VM memory, but within the hypervisor memory ensuring confidentiality and integrity of data within the VM object and therefore the guest operating system and application.

Key management is not the issue, what is the issue is how to expand this functionality to the cloud. Within a single virtual environment such functionality could work as long as the peer device could hold data for many 1000s of nodes. But once you start talking about replication sites, and moving workloads into the cloud a per host peer device may need to hold millions of keys without requiring a reboot of a node. Within increased movement of data into the cloud, such peer devices would need more and more complexity to address all the issues with movement of VM objects to and from a cloud service provider. Actually, geo-location would need to be checked before such movement as well.

Currently TPM/TXT is limited to just a single host, but that is the starting point. We have a long way to go to bring trusted launch up into the VM as well as ensuring attestation during runtime of the VM at all levels. In addition, we need to expand TPM/TXT to handle massive amounts of data as VMs are moved from host to host, host to cloud, or even cloud to cloud while maintaining the hardware root of trust.

Share this Article:

The following two tabs change content below.
Edward Haletky
Edward L. Haletky, aka Texiwill, is an analyst, author, architect, technologist, and out-of-the-box thinker. As an analyst, Edward looks at all things IoT, big data, cloud, security, and DevOps. As an author, he has written about virtualization and security. As an architect, Edward creates peer-reviewed reference architectures for hybrid cloud, cloud-native applications, and many other aspects of the modern business. As a technologist, Edward creates code prototypes for parts of those architectures. Edward is solving today's problems in an implementable fashion.
Edward Haletky

Latest posts by Edward Haletky (see all)

Related Posts:

Leave a Reply

4 Comments on "TPM/TXT Redux"

Sort by:   newest | oldest | most voted
TXT means Trusted Execution Technology, not TPM Extensions. It uses the TPM during a trusted boot to store measurements of the BIOS and operating system — or the hypervisor in a virtualized environment. Once a trusted hypervisor is launched it can measure guest VM’s before launching or resuming them and use the TPM to provide tamper-detection for the VM launch log. This is up to hypervisor vendors to implement. Same for migrating VMs between trusted hosts — that’s the job of the hypervisor & scheduler. Not clear what you mean by TPM/TXT is limited to a single host… because the… Read more »


If we use TPM/TXT in a cluster you have to maintain it across each node. If it is enabled for the virtual machine manager startup (which it can be), then on a live migration/vMotion should not TPM/TXTs state also migrate? If we go a step further and there is a virtual TPM/TXT, TPM/TXT has to become cluster aware within a virtual environment where the workloads are moving around the environment.

Best regards,


In line with the statements about maintaining the TPM/TXT state in a cluster, is there any more information about this available?
I.e. was the last statement a postulation or a statement of fact?

Do/can VMWare ESXi 5.1 clusters support the migration of VMs between hosts (hypervisors) when TPM or TXT is enabled and used?




Yes you can move a VM from one system to another even with TPM/TXT involved for several reasons:
1) the VM to VM migration starts by starting a new VM container on the new host (hence another TXT context) and then copies the data from one VM to another (memory, CPU instructions)
2) the capability that I spoke about is not 100% implemented yet.

Check out Trapezoid ( for some cool implementations using TPM/TXT.

Best regards,
Edward Haletky