Clarifying OpenHCL-based attestation vs Hyper-V checks

[hyperfinitism]

First of all, thank you for launching cvmtool. It is great to see an early effort toward a TEE-agnostic CVM attestation tool.

As I mentioned in a recent snpguest issue, I wanted to briefly summarize a few architectural points here and link to the more detailed discussion.

Key points:

1. In Azure CVMs, the vTPM-based attestation flow is provided by the OpenHCL, which is an open source paravisor running inside the guest VM at a privileged level (VMPL0 for SEV-SNP, L1 VM for TDX). It is not a feature provided by the Microsoft Hyper-V hypervisor.
2. Therefore, checks that specifically target the Hyper-V hypervisor (e.g. src/azure/cpuid.rs) may be semantically irrelevant.
3. There are plans for OpenHCL to support virtualisation by non-Hyper-V hypervisors in the future, and in principle the same OpenHCL-based attestation flow can be used outside Azure as well. In that sense, this is not strictly an "Azure-CVM-only” flow.
4. If the goal is to confirm "SEV-SNP or TDX isolation + OpenHCL-backed vTPM" on Azure VM, querying IMDS for instance metadata and checking that the VM is provisioned as a ConfidentialVM is likely a more robust and semantically direct approach.

For a more detailed explanation and background, please see the original discussion in snpguest:
virtee/snpguest#142

References

• Caroline Perez-Vargas (Microsoft), OpenHCL: the new, open source paravisor, Windows OS Platform Blog
• Caroline Perez-Vargas (Microsoft), OpenHCL - Tech Talk (YouTube Video), Confidential Computing Consortium TAC Meeting. slide available
• Chris Oo (Microsoft), OpenHCL: A Linux and Rust based paravisor, Linux Plumbers Conference