According to our understanding, the advantage of Confidential Computing VMs is that it is no longer required to trust the CSP (Microsoft). We tried to configure such a Confidential AMD SEV-SNP VM in Azure.
Our expectation was that for such a VM, we can obtain attestation reports (via some counterpart to /dev/sev-guest on KVM-based hypervisors) from within the VM and that we are able to verify the attestation report measurement through calculating the hash of the open source firmware (e.g., OVMF), and ideally kernel and user-space (e.g. through https://edk2.groups.io/g/devel/topic/patch_v3_0_2_ovmfpkg/97335488). This way, we would have been able use measured user space software to establish TLS connections bound to the attestation (through using the TLS master exporter secret as the SNP report nonce) and avoid man-in-the-middle attacks.
From our understanding, this breaks the security model for CVMs as the closed source HCL running with highest privileges in VMPL0 is able to access everything, so full trust in Microsoft is required, as the closed source firmware cannot be verified.
Is this correct, and if so:
Do you plan to open source the measured firmware including HCL and vTPM so that an actual attestation with trust only rooted to AMD (for SEV-SNP) will be possible?
Is or will there be any possibility to use custom guest firmware, e.g. to be able to measure the kernel and extend the chain of trust to the user space
According to our understanding, the advantage of Confidential Computing VMs is that it is no longer required to trust the CSP (Microsoft). We tried to configure such a Confidential AMD SEV-SNP VM in Azure.
Our expectation was that for such a VM, we can obtain attestation reports (via some counterpart to /dev/sev-guest on KVM-based hypervisors) from within the VM and that we are able to verify the attestation report measurement through calculating the hash of the open source firmware (e.g., OVMF), and ideally kernel and user-space (e.g. through https://edk2.groups.io/g/devel/topic/patch_v3_0_2_ovmfpkg/97335488). This way, we would have been able use measured user space software to establish TLS connections bound to the attestation (through using the TLS master exporter secret as the SNP report nonce) and avoid man-in-the-middle attacks.
However, according to https://github.com/Azure/confidential-computing-cvm-guest-attestation/blob/main/cvm-guest-attestation.md the firmware that is measured is HCL, vTPM and UEFI firmware which is "provided and managed by Microsoft and are currently closed source".
From our understanding, this breaks the security model for CVMs as the closed source HCL running with highest privileges in VMPL0 is able to access everything, so full trust in Microsoft is required, as the closed source firmware cannot be verified.
Is this correct, and if so: