We design and build deterministically modeled systems which use Intel Trusted Execution Technology (TXT) as the basis for the platform trust root. We have been working to develop platforms based on TPM2/TXT hardware in order to support future development paths since TPM 1.2 based hardware systems are being phased out. In the process of doing this we have run into a number of issues and wanted to get some feedback from others who may be working in this venue. We are posting here since TXT is a vPro branding element and there doesn't appear to be a forum specific to TXT issues, at least none that we could find.
First of all, for the benefit of others, it does not appear that the TBOOT hypervisor, as of its most recent 1.9.5 release, can properly implement a TPM2 based measured launch environment. There is a system initialization ordering problem which results in a null-pointer de-reference when the TPM2 initialization code attempts to read the Authenticated Code Module (ACM) header to determine the TPM2 device characteristics which are supported by the ACM. This causes the TPM2 initialization code to use random data from memory to sets its operational characteristics. At least in our environment this causes tboot to use the 'new' NVram indexes on its first invocation and the 'old' NVram indexes on its second invocation by the ACM after the dynamic root of trust has been initialized. There are also the obvious security concerns associated with null pointer de-references.
Secondly, with respect to NVram indexes. Why do the Intel TXT provisioning tools default to using the 'new' NVram indexes when all of the micro-architectures which support TPM2, ie. from Broadwell forward, have Intel released ACM's which specify that the 'old' NVram indexes are to be used? Are the 'new' indexes reserved for server class hardware which have the ACM embedded in their firmware? It is our understanding that an alternate ACM can be loaded in the multiboot stack, but if all of the alternate ACM's available on Intel's TXT site specify the 'old' indexes this would cause platform operability issues since the TPM provisioning will be incompatible with the ACM.
The final issue which we wanted to toss out, which is problematic from a security perspective, is that TBOOT appears to be unable to conduct post-S3 suspend memory verification on TPM2 based systems. It appears that TBOOT is unable to reference the ephemeral primary key which is generated on platform boot and which is used as the trust anchor for the key which is generated to seal the Message Authentication Code (MAC) secret. As a result the hypervisor cannot verify that the memory contents coming out of suspend are the same as the contents going into suspend.
After an initial TBOOT based launch one of the transient handles appears to be in use. After an S3 suspend all of the transient handles are available so our assumption is that the transient handle used by TBOOT for the sealing key is flushed as part of powering down the hardware. The TPM2 hardware is reporting a 0x910 error during S3 resume processing which indicates that the transient object being requested is not loaded so the observed behavior is consistent with the premise for the regression.
Any comments or reflections on the above, along with experiences of others working on TPM2/TXT based systems would be of interest.
Have a good day.