On Mon, Jun 30, 2025 at 02:17:18PM +0800, Zhenzhong Duan wrote:
> When 'tdx' is used, the VM will be launched with Intel TDX feature enabled.
> TDX feature supports running encrypted VM (Trust Domain, TD) under the
> control of KVM. A TD runs in a CPU model which protects the confidentiality
> of its memory and its CPU state from other software.
>
> There are four optional child elements. Element policy is 64bit hex, bit 0
> is set to enable TDX debug, bit 28 is set to enable sept-ve-disable, other
> bits are reserved currently. When policy isn't specified, QEMU will use its
> own default value 0x10000000. mrConfigId, mrOwner and mrOwnerConfig are
> base64 encoded SHA384 digest string.
>
> For example:
>
> <launchSecurity type='tdx'>
> <policy>0x10000001</policy>
> <mrConfigId>xxx</mrConfigId>
> <mrOwner>xxx</mrOwner>
> <mrOwnerConfig>xxx</mrOwnerConfig>
> </launchSecurity>
>
> Signed-off-by: Zhenzhong Duan <zhenzhong.d...@intel.com>
> ---
> src/conf/domain_conf.c | 49 +++++++++++++++++++++++++++++++
> src/conf/domain_conf.h | 11 +++++++
> src/conf/domain_validate.c | 1 +
> src/conf/schemas/domaincommon.rng | 32 ++++++++++++++++++++
> src/conf/virconftypes.h | 2 ++
> src/qemu/qemu_cgroup.c | 1 +
> src/qemu/qemu_command.c | 2 ++
> src/qemu/qemu_driver.c | 1 +
> src/qemu/qemu_firmware.c | 1 +
> src/qemu/qemu_namespace.c | 1 +
> src/qemu/qemu_process.c | 2 ++
> src/qemu/qemu_validate.c | 1 +
> src/security/security_dac.c | 2 ++
> 13 files changed, 106 insertions(+)
> diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c
> index 2d0ec0b4fa..6c65a2751b 100644
> --- a/src/qemu/qemu_firmware.c
> +++ b/src/qemu/qemu_firmware.c
> @@ -1371,6 +1371,7 @@ qemuFirmwareMatchDomain(const virDomainDef *def,
> }
> break;
> case VIR_DOMAIN_LAUNCH_SECURITY_PV:
> + case VIR_DOMAIN_LAUNCH_SECURITY_TDX:
> break;
> case VIR_DOMAIN_LAUNCH_SECURITY_NONE:
> case VIR_DOMAIN_LAUNCH_SECURITY_LAST:
We need a patch in this series that updates qemuFirmwareMatchDomain
to handle TDX guests.
Currently with
<os firmware="efi">
<type arch="x86_64" machine="q35">hvm</type>
<boot dev="hd"/>
</os>
we are *not* matching the right firmware imagte
qemuFirmwareMatchDomain:1383 : Firmware
'/usr/share/qemu/firmware/30-edk2-ovmf-4m-qcow2-x64-sb-enrolled.json' matches
domain requirements
qemuFirmwareFillDomainModern:1743 : Found matching firmware (description path
'/usr/share/qemu/firmware/30-edk2-ovmf-4m-qcow2-x64-sb-enrolled.json')
qemuFirmwareEnableFeaturesModern:1439 : decided on firmware
'/usr/share/edk2/ovmf/OVMF_CODE_4M.secboot.qcow2' template
'/usr/share/edk2/ovmf/OVMF_VARS_4M.secboot.qcow2'
qemuFirmwareEnableFeaturesModern:1473 : Enabling SMM feature
qemuFirmwareEnableFeaturesModern:1476 : Enabling secure loader
and so we fail to boot as SMM is incompatible with TDX, as
well as incorrectly setting up separate NVRAM.
The file we should have matched is
/usr/share/qemu/firmware/60-edk2-ovmf-x64-inteltdx.json
Which has the right feature for TDX launch security:
"features": [
"enrolled-keys",
"intel-tdx",
"secure-boot",
"verbose-dynamic"
],
there is already logic in qemu_firmware.c for SEV/SNP,
and the same design pattern should work for TDX too.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
