Consistent design of environment sanity check `snpguest ok`

[hyperfinitism]

Currently, when the --platform flag is used with the report command, an MS Azure Hyper-V activation check is performed. To clarify separation of responsibilities:

• snpguest report → just retrieves reports
• snpguest ok → environment sanity check

Proposal:

• Move the Hyper-V checks to: snpguest ok --new-flag-for-azure-cvm
• Avoid running sanity check during report retrieval

This aligns behavior with cases without the --platform flag and separates environment sanity check from attestation logic.

[hyperfinitism]

I think there is a more fundamental issue underlying this inconsistency.

The Azure CVM-specific attestation flow is provided by OpenHCL, a paravisor running inside the guest VM (similar in spirit to Coconut-SVSM), rather than by the Microsoft Hyper-V hypervisor. While OpenHCL currently assumes a Hyper-V-based environment, there are explicit plans for it to support other hypervisors in the future, as discussed in the Confidential Computing Consortium TAC meeting.

From this perspective, checks that are specifically tied to Hyper-V may be conceptually irrelevant to the actual attestation mechanism for Azure CVM. What really matters is the presence of the OpenHCL-provided attestation path, not whether the underlying hypervisor is Hyper-V.

This suggests that the current behavior — where Azure CVM report retrieval always performs environment checks — may be conflating Hyper-V with OpenHCL-based attestation. As a result, the design might not generalise well once OpenHCL becomes available on non-Hyper-V platforms.

It may be worth re-evaluating what conditions are truly essential for the Azure/OpenHCL attestation flow, and whether those checks should be modeled in terms of the attestation provider (OpenHCL) rather than the hypervisor.

[hyperfinitism]

For Azure CVMs, a more semantically direct (and likely more robust) environment check than "is this Hyper-V?" would be to retrieve instance metadata from Azure IMDS API (169.254.169.254/metadata/instance) and validate that the instance is configured as a Confidential VM with vTPM enabled:

• compute.securityProfile.securityType == "ConfidentialVM"
• compute.securityProfile.virtualTpmEnabled == true

That is a clear signal that the VM is an Azure Confidential VM with the vTPM-backed flow expected for Azure/OpenHCL attestation. This also avoids coupling the check to Hyper-V specifically, which may become irrelevant as OpenHCL evolves beyond Hyper-V.