Bare Metal Trust Using Intel TXT

This uses Intel TXT[4], which builds a chain of trust rooted in special purpose hardware called Trusted Platform Module (TPM)[3] and measures the BIOS, boot loader, Option ROM and the Kernel/Ramdisk, to determine whether a bare metal node deployed by Ironic may be trusted.

Problem description

The bare metal tenant has the ability to introduce rootkits and other malware on the host. Prior to releasing the host to a new tenant, it is prudent to ensure the machine is in a known good state.

Using Intel TXT[4], the TPM[3], Trusted Boot[1], and remote authentication[2], it is possible to confirm that the BIOS, boot loader, Option ROM, and the Kernel/Ramdisk are all in a known good state.

Proposed change

Add a new boot mode, trusted boot:

  • Read value “capabilities:trusted_boot” from flavor. Pass boolean value “trusted_boot” to ironic.drivers.modules.deploy_utils.switch_pxe_config(). Switch to “trusted_boot” section.

  • Add a new section “trusted_boot” in PXE Configuration. It will make use of mboot.c32 which supports multiple loading. It loads TBOOT first. TBOOT will measure Kernel/Ramdisk before loading them. PXE config template:

    label trusted_boot
    kernel mboot
    append tboot.gz --- {{pxe_options.aki_path}} root={{ ROOT }} ro text
    {{ pxe_options.pxe_append_params|default("", true) }} intel_iommu=on
    --- {{pxe_options.ari_path}}


Secure Boot[5] is used for the same purpose. The main difference is secure boot will verify the signature before executing while trusted boot uses a hardware root of trust and can be configured to verify each component before executing or execute all components and capture “measurements” (aka extended hash computations) for post verification. So if a node is changed, trusted boot will still boot it up but give a warning to users. Secure boot will not boot it up at all.

They are complementary, both making the cloud more secure. It is recommended to boot nodes with secure boot under uefi and boot nodes with trusted boot under legacy BIOS. The next step is to combine them together but that is out of the scope of this spec.

Data model impact


State Machine Impact


REST API impact


Client (CLI) impact


RPC API impact


Driver API impact


Nova driver impact

Will pass the extra_spec “capabilities:trusted_boot=True” to Ironic

Ramdisk impact


Security impact

Increased confidence in bare metal nodes being free of rootkits and other malware. Intel TXT and TPM are leveraged.

Other end user impact


Scalability impact

Our experiments indicate handling concurrent attestation requests is linear in the number of requests. Attestation occurs on the node release path, and thus is not latency sensitive.

Performance Impact

There is an extra attestation step during trusted boot which spends several seconds. But for bare metal trust no dynamic attestation requests are entertained. So this is a non-issue.

Other deployer impact

  • Create a special flavor with ‘capabilities:trusted_boot=True’

  • Set trusted_boot:True as capability in

  • Additionally two items need to be provided with tftpboot/httpboot folder
    • “mboot.c32” - Support multiple loading from /usr/lib/syslinux/mboot.c32

    • “tboot.gz” - a pre-kernel module to do measurement.

  • Set up each machine, enable Intel TXT, VT-x and VT-d and take ownership of the TPM, reboots, and captures the platform configuration register (PCR) values. This is to create the whitelist values that will be registered in the attestation service at initialization time.

  • Set up an OAT-Server and create the whitelist with all known types of hardwares from previous step.

  • Create customized images with OAT-Client.

  • Run a customized script to verify the trust state of nodes when creating instances.

Developer impact




Primary assignee:


Work Items

  • Add trusted_boot section to pxe_config.template

  • Support trusted_boot flag and switch to trusted_boot.

  • A dib element to create customized images.


  • TBOOT[1]

  • OAT[2]

  • Hardware Support: TPM and Intel TXT


Will add unit tests. Planning on adding third party hardware CI testing.

Upgrades and Backwards Compatibility

None. Backwards compatibility is achieved by not requesting “trusted” bare metal. Custom tenant images are accommodated by deploying an initial standard image that has the OAT client embedded. Today Fedora releases come bundled with the OAT client. This solution approach, while increasing the number of boots preserves us from having to doctor the tenant image by way of injecting the OAT client into the same, or requiring that bare metal users provide images with an OAT client included.

Documentation Impact

Will document usage and benefits. Here is a doc for the technical detail of Bare metal trust: