Full support for Azure Confidential VM (CVM) attestation flow

[hyperfinitism]

Architecture of Azure CVM

On Azure CVMs, (hardware) remote attestation is facilitated by a vTPM with two reserved NV indices:

• 0x01400001: This index stores the full Azure Attestation Report. This is a custom Azure format that wraps the underlying hardware report (e.g., SEV-SNP or TDX report).
• 0x01400002: This is a 64-byte area for the guest OS.

Boot time

The paravisor requests the attestation report (AR) from the AMD-SP using the SHA digest of the Runtime Claims as the REPORT_DATA. The Runtime Claims is a JSON consisting of AK Pub (signing public key for vTPM Quote), EK Pub, VM config, and zero-filled user-data (64 bytes HEX string). The paravisor wraps AR + JSON + other metadata into the Azure Attestation Report format and (re)writes the complete blob to the vTPM NV index 0x01400001.

This initial AR cannot bind any guest-provided data such as nonce. Therefore, there are vulnerabilities to replay attacks.

Runtime Attestation

The attestation flow for Azure CVMs is as follows:

1. The guest OS (the "Relying Party") generates 64-byte data for the attestation challenge.
2. The guest (initialises and) writes these 64 bytes to the vTPM NV index 0x01400002.
3. The Azure paravisor detects this write operation. It then constructs a new Runtime Claims JSON object, embedding the 64 bytes from the guest into the user-data field.
4. The paravisor requests a new SNP report from the AMD-SP using the SHA digest of the new Runtime Claims as the REPORT_DATA.
5. The paravisor wraps the new SNP report + JSON into the Azure report and (re)writes it to the vTPM NV index 0x01400001.
6. The guest OS reads the updated Azure report from 0x01400001. This report is cryptographically bound to the guest-provided data.
7. The guest sends the Azure report to a verifier, which can validate the signature and check that the REPORT_DATA matches the hash of the Runtime Claims JSON (incl. the guest-provided data).

# (1)
openssl rand 64 > user-data.bin
# (2)
sudo tpm2_nvdefine -C o 0x01400002 -s 64
sudo tpm2_nvwrite -C o 0x01400002 -i user-data.bin
# (3)-(5) automatically
# (6)
sudo snpguest report report.bin request-data.bin --platform
# signature verification part of (7)
snpguest fetch ca pem . -r report.bin -e vcek
snpguest fetch vcek pem . report.bin
snpguest verify attestation . report.bin

Problems

Currently, snpguest can only fetch the initial SNP report and Runtime Claims digest, and can only perform a part of step 6-7. To provide full support for Azure CVMs, snpguest should be enhanced to orchestrate this entire workflow.

Also, the current --platform flag is somewhat ambiguous. To make the tool's usage clearer, we propose renaming --platform to a more explicit name, such as --azure-cvm. This makes it evident that the flag enables a workflow specific to Azure's CVM implementation.

[hyperfinitism]

Perhaps it might be worth considering implementing this as a separate guest attestation tool for Azure CVMs, rather than as a feature within snpguest (or any future tdx_guest wrapper tools).

[tylerfanelli]

Also, the current --platform flag is somewhat ambiguous. To make the tool's usage clearer, we propose renaming --platform to a more explicit name, such as --azure-cvm. This makes it evident that the flag enables a workflow specific to Azure's CVM implementation.

Agreed.

[tylerfanelli]

The attestation flow for Azure CVMs is as follows:

1. The guest OS (the "Relying Party") generates 64-byte data for the attestation challenge.

2. The guest (initialises and) writes these 64 bytes to the vTPM NV index `0x01400002`.

3. The Azure paravisor detects this write operation. It then constructs a new `Runtime Claims` JSON object, embedding the 64 bytes from the guest into the `user-data` field.

4. The paravisor requests a new SNP report from the AMD-SP using the SHA digest of the new `Runtime Claims` as the `REPORT_DATA`.

5. The paravisor wraps the new SNP report + JSON into the Azure report and (re)writes it to the vTPM NV index `0x01400001`.

6. The guest OS reads the updated Azure report from `0x01400001`. This report is cryptographically bound to the guest-provided data.

I see no reason this tool can't handle all of this.

7. The guest sends the Azure report to a verifier, which can validate the signature and check that the `REPORT_DATA` matches the hash of the `Runtime Claims` JSON (incl. the guest-provided data).

I think this step should be done from another tool, simply because we have no expectation of what kind of verifier the evidence is being sent to.

[hyperfinitism]

Thanks for the quick reply.

I see no reason this tool can't handle all of this.

For context: Azure CVMs run the OpenHCL paravisor, not plain SEV-SNP (Narayanan et al. 2023 ). On Azure CVMs, SEV-SNP and TDX largely share the same attestation flow via OpenHCL's vTPM and IMDS. Hence a paravisor-scoped "attestation tool for CVMs with OpenHCL" clarifies scope and enables reuse across both.

That said, I'm not opposed to implementing those features within snpguest (and future TDX Guest tools).

[tylerfanelli]

We always thought of making this a cvmguest (one tool for SEV-SNP, TDX, etc). Perhaps this could be worth investigating, since SEV-SNP and TDX will behave similarly like you mention.

[hyperfinitism]

A new PR implementing Step (2) of this issue has been submitted. It now enables requesting fresh SNP attestation reports on Azure Confidential VMs:

1. Guest writes user data (64 bytes) to NV index 0x01400002
2. Paravisor requests an SNP report
3. ASP issues a fresh report
4. Paravisor places the new report in NV index 0x01400001
5. Guest parses into AttestationReport as usual

During implementation several design considerations arose:

Naming of hyperv module / feature

The current naming is misleading:

• As previously mentioned, the implemented flow is Azure Confidential VM-specific (not generic hypervisor functionality)
• The paravisor (including vTPM) executes at VMPL0 inside the guest VM (not within the host hypervisor)

Proposed alternatives for a follow-up refactor: azure_cvm, azcvm, vtpm_snp, etc.

Architectural considerations: Integration vs. Separation

Initially I considered splitting Azure CVM support into a dedicated tool (e.g. az-cvm-guest). However, recent upstream developments change the landscape: Linux kernel now supports SVSM-backed SEV-SNP attestation via Guest OS → configfs → SVSM (VMPL0) → ASP (configfs-tsm documentation). It is similar to the architecture of Azure CVMs: Guest OS → OpenHCL paravisor (VMPL0) → ASP. This style of architecture has been formally discussed in the security literature, such as Narayanan et al. Remote attestation of confidential VMs using ephemeral vTPMs. In other words, the attestation flow via vTPM is no longer specific to Azure. Thus both integration and separation appear reasonable.

Either way, I am happy to help implement the next steps, including Runtime Claims handling (e.g. Step 7) and module/feature refactors.