feat: Add Azure CVM Emulation (AzCVMEmu) support for development and testing #529

bodzhang · 2025-10-30T00:39:27Z

This commit introduces comprehensive Azure CVM emulation capabilities to enable
MigTD development and testing as a standard Rust application inside an Azure TDX CVM,
while exercising almost all MigTDCore code and flows, including RA-TLS/SPDM with TDX Quote
and migration policy enforcement.

Key Features

Emulation Infrastructure:

Relevant td-shim interfaces emulation under deps/td-shim-AzCVMEmu/
Relevant TDX TDCALL emulation
MigTD Quote emulation by Azure TDX CVM virtual FW Quote, or mock TD REPORT and Quote
Event logging emulation with CCEL (CC Event Log) interface
Interrupt handling emulation
File-based policy and root CA configuration loading
TCP transport layer for source/destination communication

MigTDCore Integration:

Conditional compilation support via AzCVMEmu feature flag
Command-line interface with argument parsing and help
Standard library (std) support for development workflows

Development and Testing Support:

migtdemu.sh runner script with automatic environment detection
CI/CD integration with GitHub Actions workflow
Documentation in doc/AzCVMEmu.md
test_disable_ra_and_accept_all support for mock attestation, enabling build and integration test on generic Linux machine

Usage Modes

Development/Testing (Azure TDX CVM + TPM2-TSS):

cargo build --no-default-features --features "AzCVMEmu" --bin migtd

Development/Testing (any Linux system):

cargo build --no-default-features --features "AzCVMEmu,test_disable_ra_and_accept_all" --bin migtd

This PR enables comprehensive end-to-end testing of MigTD's
RATLS/SPDM flow, v1-policy enforcement, and migration workflows in a broadly available development
environments. An follow-up PR will add emulation support for v2-policy.

Special acknowledgments:

src/attestation/fixup-libservtd-attest-lib.sh: Investigation, design and implementation by Mike Brasher [email protected]

Co-authored-by: Haitao Huang [email protected]
Signed-off-by: Bo Zhang (ACC) [email protected]

jyao1 · 2025-10-30T14:29:26Z

deps/td-shim-AzCVMEmu/README.md

@@ -0,0 +1,136 @@
+# TDX TDCALL TCP Emulation for Azure CVM
+
+This crate provides a drop-in replacement for the original `tdx-tdcall` crate that emulates TDX VMCALL operations using TCP transport. This enables MigTD development and testing in non-TDX environments.


I am thinking if we should add td-shim-AzCVMEmu to td-shim project, instead of MigTD project.

td-shim-AzCVMEmu layer does not fully emulate tdshim interface, only the interfaces used by MigTD in vmcall-raw transport mode. In my opinion, adding partial emulation in tdshim project will cause confusion.

Ok, that means, if some other projects are using td-shim, it cannot benefit from this?

Please forgive my ignorance, here is a general question:
Can a developer do the emulation by himself/herself, by implementing emulated content? Or he/she must rely on MSFT to implement the emulated content?

A developer can definitely implement his/her own emulation for certain tdshim interfaces. In this PR, the implementation of emulating MigTD REPORT/QUOTE with Azure TDX CVM virtual firmware REPORT/QUOTE utilizes Azure TDX CVM specific vTPM and IMDS (http endpoint) interfaces. The interface definition is published. Emulation of other supported tdshim interfaces in this PR do not have Azure-specific dependency.

I see the contradiction here.
On one hand, you want to use CVM to handle REPORT/QUOTE.
On the other hand, you say that CVM cannot emulate REPORT because REPORTDATA is handled in a different way and you want to skip.

Question: Is this a MUST that we have to use CVM to emulate REPORT/QUOTE and no other way? Why we stick to CVM?
Or, do you think if it is possible to use the same CVM way to verify REPORT, e.g. append something to original REPORTDTA? With this, we do not skip, but use emulation-specific way to verify. The benefit that the original logic can still be validated.

Emulating MigTD REPORT/QUOTE with Azure TDX CVM firmware REPORT/QUOTE gives us a simple way to exercise significant portion of MigTD code logic related to Quote generation/verification and Policy enforcement in the emulation environment. Even if the Emulation mode can't support some of the MigTD code logic related to REPORTDATA check or RTMR check, I still see the benefit of excising verify_quote_with_collaterals() code flow and platform tcbdate related Policy enforcement code flow. Adding Azure CVM REPORTDATA specific verification code in emulation mode can be done, but it still does not exercise the HW-mode MigTD code for REPORTDATA verification.

jyao1 · 2025-10-30T14:40:03Z

src/migtd/src/spdm/spdm_req.rs

+
+    #[cfg(not(feature = "test_disable_ra_and_accept_all"))]


Is this related to Azure CVM?
Or is it only a bug for test_disable_ra_and_accept_all feature?

If later, I think we need a dedicated PR. Please don't mix all good work in one (big) patch.

This is required to pass AzCVMEmu mode PR pipeline test when spdm_attestation feature is enabled. AzCVMEmu mode PE pipeline test runs on standard Github Linux VM, using mock REPORT/QUOTE, and requires test_disable_ra_and_accept_all flag. The changes are not general, to enable test_disable_ra_and_accept_all in spdm_attestation, not directly related to AzCVMEmu mode. We can move them to a separate PR.

Removed the file from this PR

jyao1 · 2025-10-30T14:40:37Z

src/migtd/src/ratls/server_client.rs

    let mut additional_data = [0u8; 64];
    additional_data[..hash.len()].copy_from_slice(hash.as_ref());
    let td_report = tdx_tdcall::tdreport::tdcall_report(&additional_data)?;
-


why change this ?

Likely a missed extra format change. Will remove from the PR.

Addressed in the update of the PR.

jyao1 · 2025-10-30T14:42:07Z

src/migtd/src/ratls/server_client.rs

+        if cfg!(feature = "AzCVMEmu") {
+            // In AzCVMEmu mode, REPORTDATA is constructed differently.
+            // Bypass public key hash check in this development environment.
+            log::warn!(
+                "AzCVMEmu mode: Skipping public key verification in TD report. This is NOT secure for production use.\n"
+            );
+            return Ok(());
+        }


I don't understand the comment. Why it is constructed differently?
Why we cannot use the original way?

In AzCVMEmu mode Azure TDX CVM firmware's REPORT/QUOTE are used to simulate MigTD QUOTE. The API to get Azure TDX CVM firmware REPORT does support passing in data to be included in REPORTDATA, but the API automatically append extra data to the passed in data, hash them all together, then set REPORTDATA. As the result, the public key hash check against REPORTDATA of the simulated QUOTE will always fail.

My question is why it cannot pass the REPORTDATA, which is a fundamental feature for TDREPORT generation. Or why it has to "automatically append extra data"?

For emulation, I hope to emulate as much as possible to reduce the change the real code.
Otherwise, we must patch here and there. And it is easy broken.

To verify the public key hash with Azure TDX CVM firmware QUOTE, the verification code will be significantly different from the HW-mode code. The verification code would need to get the extra data the Azure TDX CVM API appended to the datablob whose digest is REPORTDATA. The extra data appended to calculate the digest is not part of REPORT/QUOTE. The extra data is part of higher layer lib Azure provides. What's more, the Azure TDX CVM environment does not support extending RTMR, so it's not possible to use the exact same verification code logic in the AzCVMEmu mode as in HW mode.

OK. Then I think the description "MigTD Quote emulation by Azure TDX CVM virtual FW Quote, or mock TD REPORT and Quote" is very confusing.
It seems REPORT and Quote are NOT supported at all, if the right REPORTDATA cannot be passed in.

I recommend to list a set of feature not supported, to remind people the limitation.
Otherwise, people will think a feature is validated, but actually it is NOT.

Will add a limitation section in the AzCVMEmu doc.

jyao1 · 2025-10-30T14:43:09Z

src/migtd/src/spdm/mod.rs

+#[cfg(not(feature = "AzCVMEmu"))]
+use tdx_tdcall;
+#[cfg(feature = "AzCVMEmu")]
+use tdx_tdcall_emu as tdx_tdcall;


Can we merge this into td-shim project and let td-shim project control that?

d-shim-AzCVMEmu layer does not fully emulate tdshim interface, only the interfaces used by MigTD in vmcall-raw transport mode. In my opinion, adding partial emulation in tdshim project will cause confusion.

Partial interface should be fine. We can document the scope of emulation.
My point is that: the change should be in right place to benefit all consumers.

jyao1 · 2025-10-30T14:43:30Z

src/migtd/src/event_log.rs

+#[cfg(not(feature = "AzCVMEmu"))]
 use td_payload::acpi::get_acpi_tables;
+#[cfg(feature = "AzCVMEmu")]
+use td_shim_emu::event_log::{get_acpi_tables, MockCcel as Ccel};
+#[cfg(not(feature = "AzCVMEmu"))]
 use td_shim_interface::acpi::Ccel;
+#[cfg(not(feature = "AzCVMEmu"))]
 use tdx_tdcall::tdx;
+#[cfg(feature = "AzCVMEmu")]
+use tdx_tdcall_emu::tdx;


Can we merge this into td-shim project and let td-shim project control that?

jyao1 · 2025-10-30T14:43:52Z

src/migtd/src/config.rs

+
+#[cfg(not(feature = "AzCVMEmu"))]
 use td_shim_interface::td_uefi_pi::{fv, pi};
+#[cfg(feature = "AzCVMEmu")]
+use td_shim_interface_emu::td_uefi_pi::{fv, pi};


Can we merge this into td-shim project and let td-shim project control that?

jyao1 · 2025-10-30T14:45:03Z

src/attestation/src/lib.rs

+
+// Conditionally compile collateral for AzCVMEmu mode
+#[cfg(feature = "AzCVMEmu")]
+mod collateral;


Why we need collateral for AzCVMEmu?

In Azure environment, getting Quote Verification Collateral such as TCBINFO, QEIdentity at run time is not supported. For v1-policy build, this hardcoded Collateral is needed. With v2-policy build, Collateral will be from the v2 Policy file, and hardcoded Collateral is not required.

I am not clear on this part. Quote verification should be "software only". It is not related to hardware. What prevents the Quote verification in emulation mode?

Quote verification process uses the Collateral. For v1-policy build, the HW-mode implementation of MigTD retrieves the Collateral from outside of MigTD. The mechanism is not supported in Azure environment.

If you worry V1-policy, can we drop V1-policy in emulation mode, and only support V2-policy in emulation mode?
I think we only support test_disable_ra_and_accept_all and raw-data, it is fine to add one more constrain.

Once AzCVMEmu emulation support for v2-policy is ready, removing v1-policy support in AzCVMEmu mode to avoid code deviation from HW mode is an option.

AzCVMEmu mode does support exercising QUOTE generation/verification and policy enforcement, which are not exercised in test_disable_ra_and_accept_all. If test_disable_ra_and_accept_all is not enabled in AzCVMEmu mode, the emulation layer will retrieve and return Azure TDX CVM's virtual firmware REPORT/QUOTE to the emulation mode MigTD. MigTD code logic related to Quote generation/verification and Policy enforcement will all be exercised. With test_disable_ra_and_accept_all enabled in AzCVMEmu mode, the emulation mode MigTD skips QUOTE/Policy related code flow and can run on any Linux machine or VM.

jyao1 · 2025-10-30T14:53:55Z

I think it is a good feature. Some general comment:

The patch is too big. 61 files change in 1 commit. It is hard for review. I suggest to split the commit.

Especially for the one irrelevant to AzCVMEmu, or some pre-work. For example, the fix for test_disable_ra_and_accept_all should be in a dedicated PR. Also some "easy" fixes, such as remove comma, remove space, remove line. Please submit a patch to fix those typo. I think those are easy to review and merge.
This PR should only handle AzCVMEmu. Nothing else.

I am wondering if we merge AzCVMEmu feature to td-shim. I assume that can help to enable AzCVMEmu for other project which is using td-shim. No need to duplicate code.
If possible, I recommend we reduce the usage of "feature = "AzCVMEmu". The interface is to allow us hide the implementation detail. If we can figure out a way to use existing API, we should.
license header is required for the new files.

jyao1 · 2025-10-30T16:02:30Z

deps/td-shim-AzCVMEmu/td-payload-emu/src/arch/idt/mod.rs

@@ -0,0 +1,16 @@
+use interrupt_emu as intr;


need license header

Addressed in the update of this PR.

jyao1 · 2025-10-30T16:02:54Z

deps/td-shim-AzCVMEmu/interrupt-emu/src/lib.rs

@@ -0,0 +1,30 @@
+// Interrupt emulation registry for AzCVMEmu.


need license header.

Addressed in the update of this PR.

jyao1 · 2025-10-30T16:03:19Z

deps/td-shim-AzCVMEmu/td-payload-emu/src/lib.rs

@@ -0,0 +1,23 @@
+#![cfg_attr(not(test), no_std)]


need license header.

Addressed in the update of this PR.

jyao1 · 2025-10-31T17:16:24Z

Hi
Thanks to address the license header comment. However, it should not be addressed in a dedicated commit, such as 4ac741c.
The license header should come together with the original code.

The rule to split the commit should be based on feature, but not how the code is developed.

…testing This commit introduces comprehensive Azure CVM emulation capabilities to enable MigTD development and testing as a standard Rust application inside an Azure TDX CVM, while exercising almost all MigTDCore code and flows, including RA-TLS with TDX Quote and migration policy enforcement. **Emulation Infrastructure:** - Relevant td-shim interfaces emulation under `deps/td-shim-AzCVMEmu/` - Relevant TDX TDCALL emulation - MigTD Quote emulation by Azure TDX CVM virtual FW Quote, or mock TD REPORT and Quote - Event logging emulation with CCEL (CC Event Log) interface - Interrupt handling emulation - File-based policy and root CA configuration loading - TCP transport layer for source/destination communication **MigTDCore Integration:** - Conditional compilation support via `AzCVMEmu` feature flag - Command-line interface with argument parsing and help - Standard library (std) support for development workflows **Development and Testing Support:** - `migtdemu.sh` runner script with automatic environment detection - CI/CD integration with GitHub Actions workflow - Documentation in `doc/AzCVMEmu.md` - `test_disable_ra_and_accept_all` support for mock attestation, enabling build and integration test on generic Linux machine **Development/Testing (Azure TDX CVM + TPM2-TSS):** ```bash cargo build --no-default-features --features "AzCVMEmu" --bin migtd ``` **Development/Testing (any Linux system):** ```bash cargo build --no-default-features --features "AzCVMEmu,test_disable_ra_and_accept_all" --bin migtd ``` This implementation enables comprehensive end-to-end testing of MigTD's RATLS, policy enforcement, and migration workflows in a broadly available development environments. Special acknowledgments: - src/attestation/fixup-libservtd-attest-lib.sh: Investigation, design and implementation by Mike Brasher <[email protected]> Co-authored-by: Haitao Huang <[email protected]> Signed-off-by: Bo Zhang (ACC) <[email protected]>

bodzhang · 2025-10-31T19:33:24Z

Hi Thanks to address the license header comment. However, it should not be addressed in a dedicated commit, such as 4ac741c. The license header should come together with the original code.

The rule to split the commit should be based on feature, but not how the code is developed.

Thanks for pointing out the expectation. The PR is updated, with the second commit squashed with the first one.

bodzhang requested a review from jyao1 as a code owner October 30, 2025 00:39

bodzhang force-pushed the azcvmemu-for-upstream branch from a2d7385 to 15b1460 Compare October 30, 2025 00:49

jyao1 reviewed Oct 30, 2025

View reviewed changes

bodzhang force-pushed the azcvmemu-for-upstream branch 2 times, most recently from a86f430 to 8b1a590 Compare October 30, 2025 17:14

bodzhang force-pushed the azcvmemu-for-upstream branch from 4ac741c to 51cc38d Compare October 31, 2025 19:31

		@@ -0,0 +1,136 @@
		# TDX TDCALL TCP Emulation for Azure CVM

		This crate provides a drop-in replacement for the original `tdx-tdcall` crate that emulates TDX VMCALL operations using TCP transport. This enables MigTD development and testing in non-TDX environments.

		@@ -0,0 +1,30 @@
		// Interrupt emulation registry for AzCVMEmu.

feat: Add Azure CVM Emulation (AzCVMEmu) support for development and testing #529

Are you sure you want to change the base?

feat: Add Azure CVM Emulation (AzCVMEmu) support for development and testing #529

Uh oh!

Conversation

bodzhang commented Oct 30, 2025

Key Features

Usage Modes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jyao1 Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jyao1 Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jyao1 Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jyao1 commented Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jyao1 Oct 30, 2025 •

edited

Loading

jyao1 Oct 30, 2025 •

edited

Loading

jyao1 Oct 30, 2025 •

edited

Loading

jyao1 commented Oct 30, 2025 •

edited

Loading