Guest Deployment

Guest Deployment Sequence (figure from here)

After authenticating the SEV firmware and the PDH, the guest can deploy its VM. In addition to the initial guest image, an encrypted disk image containing sensitive data should be provided. The reason is that the initial VM needs to be deployed by the hypervisor and therefore the hypervisor can read all the data it contains. The encrypted disk image will later be decrypted with the TEK and integrity checked with the TIK. In addition, the guest must send a policy to define what actions the cloud provider is not allowed to perform on the VM, such as disabling migration and minimum SEV API version. (Step 1)

If the VM is deployed successfully, the hypervisor will contact the SEV firmware to encrypt the memory (Step 2). The firmware then hashes the initial plaintext VM memory (Step 3). The hash, the guest policy, and the SEV API version are transferred from the firmware to the guest owner over the secure channel (Step 4). Since we trust the SEV firmware, we can infer the integrity of the guest VM from the hash value sent. Finally, the guest sends the TEK and TIK to the firmware, which forwards them to the guest VM to decrypt the disk image (step 5 & 6).

Remote attestation reports are signed with the CEK by the AMD SP and include the measurement, the guest owner's identity, and optional user data.

To migrate a guest VM, the guest policies must allow migration and the target minimum SEV API version must be met. After establishing the secure channel between two SEV firmware, the TEK and TIK will protect the integrity and confidentiality during the migration. After migration, the target SEV firmware will encrypt the VM with newly generated keys.