VM Launch & Attestation
Last updated
Was this helpful?
Last updated
Was this helpful?
Similar to previous SEV and SEV-ES architectures, SEV-SNP VMs start from an initial unencrypted image that typically includes the guest VM's boot code and other non-sensitive data. During the launch process, the hypervisor requests the AMD-SP to install this initial set of pages in the guest. The AMD-SP measures the contents of these pages cryptographically to generate a launch digest. Additionally, SEV-SNP extends this process to include measuring the metadata associated with these pages, such as the guest physical address (GPA) where the pages are placed and their type, ensuring that the launch digest captures both the layout and contents of the initial guest memory.
In SEV-SNP, after the launch process, the guest owner can provide a signed Identity Block (IDB) to associate with the VM. The IDB contains fields that uniquely identify the VM and includes the expected launch digest. The IDB can only be associated with VMs that match the expected launch digest, and it becomes part of the attestation report.
Unlike SEV and SEV-ES, which support attestation only during guest launch, SEV-SNP provides more flexible attestation capabilities. Attestation reports can be requested from the AMD-SP by the guest VM through a protected path at any time. During SEV-SNP VM launch, a set of private communication keys is created by the AMD-SP, enabling the guest to communicate directly with the AMD-SP. This path allows the guest to request attestation reports, cryptographic keys, and other information as needed.
Attestation reports contain the IDB information from launch, system details, and a block of arbitrary data supplied by the guest VM as part of the report request. The attestation report is signed by the AMD-SP firmware using the VCEK. These reports enable third parties, such as the guest owner, to validate that specific data originated from a particular VM.
For instance, a VM can publish a public key and request an attestation report containing the hash of this public key. A third party can then verify the association between the public key and the VM through the attestation report. The report also serves as proof that the VM operated with the appropriate security features enabled and started on an authentic AMD platform. Since the attestation report is signed by the VCEK, its verification confirms both the authenticity of the platform and the TCB version in use (as the VCEK is derived from the TCB version). Upon successful attestation, the guest owner can decide to provide the VM with secrets, like disk decryption keys or other necessary operation keys.
Furthermore, SEV-SNP supports various use models for generating guest key material. VMs can directly request keys from the AMD-SP for specific purposes, such as data sealing. These keys can be derived from different sources, and the VM can select which sources to use based on their use case. For example, local sealing keys may be requested, which are specific to the current part at a certain TCB level and particular to the IDB signing key. These controls ensure that the VM can request keys that cannot be derived by malicious actors or other devices, enhancing the security of the system.