After discussing this with the Red Hat grub maintainer and the Red Hat UEFI maintainer, we have concluded that tboot cannot be securely adapted to work with UEFI for the following reasons. 

If we made all the changes necessary to support tboot in EFI Secure Boot mode, there is the possibility that tboot would load a blacklisted kernel, because it checks with the TPM hardware for hashes, not with EFI for keys. This is a security regression from Secure Boot mode.

Also, the necessity to use the multiboot module in grub in order to load tboot presents another regression from Secure Boot mode.

Furthermore, tboot is specific to x86_64 hardware, so it is not a generic root-of-trust solution, whereas Secure Boot is. 

We are devising patches that will gracefully reject creating tboot stanzas in grub.cfg or even installing tboot on a system with an EFI partition, but they will not be ready in time for RHEL6.8. Meanwhile, we must advise against using tboot on systems installed with EFI partitions.

However, the tboot package continues to provide good security for legacy BIOS systems, and has been updated to include the latest upstream patches as of March 1, 2016, which fixes some known bugs. 

See advisory "RHBA-2016:22981-02 tboot bug fix and enhancement update".

UEFI secure boot is different from Intel TXT trusted boot.
Intel TXT trusted boot can boot from UEFI BIOS when UEFI is not in Secure mode.

tboot with UEFI is unsupported. 

tboot cannot be loaded by grub2-efi without the addition of the multiboot2 and relocator grub2 modules. 

Red Hat as decided not to include these modules in the grub2-efii build, because multiboot2 presents a security risk. 

Furthermore, tboot could load an image that is blacklisted by Secure Boot, which presents yet another security threat.

If you have UEFI, use Secure Boot. Not only is it a more secure technology, it is more generic and can be deployed across different architectures without any architecture-specific provisioning.

Under UEFI, there are two modes, one is secure boot mode, another is non-secure boot mode.
In non-secure boot mode, tboot still can work with UEFI for platform trust and attestation, just like tboot in legacy BIOS environment.
in this way, we can provides more choices to end users for their security requirements.

(In reply to nsun1 from comment #5)
> Under UEFI, there are two modes, one is secure boot mode, another is
> non-secure boot mode.
> In non-secure boot mode, tboot still can work with UEFI for platform trust
> and attestation, just like tboot in legacy BIOS environment.
> in this way, we can provides more choices to end users for their security
> requirements.

While this is true, grub2-efi does not contain the mutliboot2 module necessary to launch a kernel via tboot, due to the security compromise it introduces in Secure Boot mode. We are looking for a way to address this, but meanwhile we cannot say that we support it.

See https://access.redhat.com/articles/2217041

I understand your concern about multiboot2 presenting a security risk,
since this enables loading of multiboot-type modules that are not 
signature checked by SHIM.

However GRUB does support signature checking of loaded multiboot-type modules.
If this is enabled, does this address your concerns ?

i.e.
UEFI would check SHIM
SHIM would check GRUB (with multiboot built in)
GRUB would check tboot (loaded via multiboot )
GRUB would check kernel (loaded via multiboot, on request from tboot )

( i think ... apologize, i'm not a shim, grub, boot firmware expert )

tboot does NOT work with UEFI in any RHEL.

There are no plans of which I am aware to install the necessary the multiboot modules in RHEL to do so.

Just fyi, the rationale for wanting tboot and UEFI Secure Boot to work together is as follows:
- UEFI Secure Boot provides a fairly easy way to administer Secure Boot Keys in order to provide secure booting of a server; i.e. typically with signature checks of shims, boot loaders, kernel and even kernel modules,
- tboot provides measurements and optional boot time checks of similar items; but also includes hardware bios type measurements.  These measurements are stored in PCR registers of TPM Security Device which can then be used as a source of info and mechanism for the server to interwork with Remote Attestation Servers.
- the downside of tboot is that the optional boot time checks, managed thru Launch Control Policies (LCP), are actually administratively difficult to manage ... at least compared to the management of Secure Boot keys for UEFI Secure Boot.

So the reason for looking for both tboot and UEFI Secure Boot was to get the best of both worlds, i.e.
- administratively easy management of secure booting of a server from UEFI Secure Boot, and
- support for secure measurements of ALL components of server, hardware up to application space, and support of Remote Attestation clients ... from tboot