edk2/OvmfPkg/IntelTdx
Luigi Leonardi 35345c76a9 OvmfPkg/IntelTdx: Add memory debug logging support for TDX guests
OVMF already supports MemDebugLogLib for capturing firmware debug
output in a runtime memory buffer. Align the TDX peiless boot path
with OVMF by integrating the same library, so that TDX guests can
use memory-based debug logging.

In PeilessStartupLib, allocate a runtime buffer for the debug log
during PeilessStartup() and copy any early SEC-phase logs from
the pre-allocated FDF region into it.

Register the early debug log memory region in the TDX metadata as
TEMP_MEM so the TDX module accepts it during guest initialization.

Move PlatformDxe/Platform.inf from NCCFV to DXEFV because it
exposes the memory debug log HOB to the guest.

Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
2026-07-22 09:00:42 +00:00
..
PrePiHobListPointerLibTdx OvmfPkg: Use PcdOvmfWorkAreaBase instead of PcdSevEsWorkAreaBase 2022-06-16 08:08:19 +00:00
Sec MdePkg: Move StackCheckLibStaticInit to StackCheckLib 2025-02-07 02:23:11 +00:00
TdxHelperLib OvmfPkg/IntelTdx: Fix TDVF boot failure with odd-sized memory below 2816M 2025-09-25 08:59:57 +00:00
TdxMeasurementLib OvmfPkg: Implement TdxMeasurementLib 2025-01-13 09:38:39 +00:00
IntelTdxX64.dsc OvmfPkg/IntelTdx: Add memory debug logging support for TDX guests 2026-07-22 09:00:42 +00:00
IntelTdxX64.fdf OvmfPkg/IntelTdx: Add memory debug logging support for TDX guests 2026-07-22 09:00:42 +00:00
README.md OvmfPkg/IntelTdx: Update README.md with missing build command 2026-03-16 02:55:54 +00:00

TDVF Overview

Intel Trust Domain Extension (TDX) is Intel Architecture extension to provide trusted, isolated VM execution by removing CSP software (hypervisor etc) from the TCB. TDX Virtual Firmware (TDVF) is an EDK II based project to enable UEFI support for TDX based Virtual Machines. It provides the capability to launch a TD.

The Intel TDX Virtual Firmware Design Guide is at https://www.intel.com/content/dam/develop/external/us/en/documents/tdx-virtual-firmware-design-guide-rev-1.01.pdf.

More information can be found at: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html

Configurations and Features

There are 2 configurations for TDVF.

Config-A:

  • Merge the basic TDVF feature to existing OvmfPkgX64.dsc. (Align with existing SEV)
  • Threat model: VMM is NOT out of TCB. (We don't make things worse)
  • The OvmfPkgX64.dsc includes SEV/TDX/normal OVMF basic boot capability. The final binary can run on SEV/TDX/normal OVMF.
  • No changes to existing OvmfPkgX64 image layout.
  • No need to remove features if they exist today.
  • PEI phase is NOT skipped in either TD or Non-TD.
  • RTMR based measurement (CC_MEASUREMENT) is supported as an optional requirement.
  • External inputs from Host VMM are measured, such as TdHob, CFV.
  • Other external inputs are measured, such as FW_CFG data, os loader, initrd, etc.

Config-B:

  • Add a standalone IntelTdxX64.dsc to a TDX specific directory (OvmfPkg/IntelTdx) for a full feature TDVF.(Align with existing SEV)
  • Threat model: VMM is out of TCB. (We need necessary change to prevent attack from VMM)
  • IntelTdxX64.dsc includes TDX/normal OVMF basic boot capability. The final binary can run on TDX/normal OVMF.
  • It might eventually merge with AmdSev.dsc, but NOT at this point of time. And we don't know when it will happen. We need sync with AMD in the community after both of us think the solutions are mature to merge.
  • RTMR based measurement (CC_MEASUREMENT) is supported as a mandatory requirement.
  • External inputs from Host VMM are measured, such as TdHob, CFV.
  • Other external inputs are measured, such as FW_CFG data, os loader, initrd, etc.
  • PEI phase is skipped to remove unnecessary attack surface.
  • DXE FV is split into 2 FVs (DXEFV & NCCFV) to remove the unnecessary attack surface in a TD guest..
    • When launching a TD guest, only drivers in DXEFV are loaded.
    • When launching a Non-TD guest, dirvers in both DXEFV and NCCFV are loaded.

Build

For the build environment, consider reusing the existing EDKII infrastructure for containerized builds. See tianocore/containers for more details.

  1. (Optional) Pull and run the tianocore/containers Ubuntu 22 Docker image:

    docker run -it \
      -v "${HOME}":"${HOME}" \
      -e EDK2_DOCKER_USER_HOME="${HOME}" \
      ghcr.io/tianocore/containers/ubuntu-22-dev:latest /bin/bash
    
  2. Prepare the environment:

    cd /path/to/edk2
    . ./edksetup.sh
    make -C BaseTools
    
  3. Build the TDVF target:

    Config-A (OvmfPkgX64):

    # CC_MEASUREMENT disabled
    build -p OvmfPkg/OvmfPkgX64.dsc -a X64 -t GCC -D CC_MEASUREMENT_ENABLE=FALSE -b RELEASE
    
    # CC_MEASUREMENT enabled
    build -p OvmfPkg/OvmfPkgX64.dsc -a X64 -t GCC -D CC_MEASUREMENT_ENABLE=TRUE -b RELEASE
    

    Config-B (IntelTdxX64):

    build -p OvmfPkg/IntelTdx/IntelTdxX64.dsc -a X64 -t GCC -b RELEASE
    

Usage

Assuming TDX-QEMU/TDX-KVM are already built, one can start a TD virtual machine as launching-a-tdx-vm:

qemu_system_x86 \
   -accel kvm \
   -cpu host \
   -object tdx-guest,id=tdx0 \
   -machine ...,confidential-guest-support=tdx0 \
   -bios /path/to/OVMF.fd

Note: Avoid using the '-pflash' QEMU parameter with TDX configurations, as TDX lacks support for read-only memory slots.

Linux Software Stack

KVM with TDX support:

QEMU with TDX support: