AMD Secure VM Service Module and vTPMs
In this article we summarise the concept of vTPM-based attestation leveraging the Secure Virtual Machine Service provided by AMD SEV technology.
The extensive use of Virtual Machines, particularly by Cloud Providers that share computing resources through virtualization-based isolation, introduces significant security challenges. These challenges must be addressed to ensure that sensitive data is not exposed to the Cloud Provider via its hypervisor. Confidential Execution Environments (CEEs) offer solutions by enabling the CPU to isolate different Virtual Machines during execution, utilizing technologies such as memory encryption and integrity protection.
How can we trust an enclave?
A key challenge in designing Confidential Execution Environments is ensuring the confidentiality and integrity of the code running within the Trusted Computing Base (TCB) and, in certain scenarios, proving its soundness to a third party with a remote attestation. Verifying the soundness of the TCB to a third party is crucial, as the user must be confident that the guarantees provided by the CEE are genuine and not being manipulated through the hypervisor or while the VM image was stored in a volume. This is particularly important when provisioning keys for Full Disk Encryption (FDE), Transparente Data Encryption (TDE) of databases or migrating a VM between CPUs in a data center.
Raw platform attestation
Proving that the CEE runs on an hardware enabled platform with the necessary settings in place can be proven through the attestation mechanism that is provided through the platform security processor. In the case of AMD-SEV the report consists of the platform configuration and the initial guest state which includes the Virtual Machine's firmware. Other components as the kernel or initrd are not included in the report.
The platform configuration consists of the SNP security processor firmware, x86 microcode, boot loader and operating system of the AMD Security Processor. Every component is represented through a security version number (SVN) which represents the current version of their respective component. The initial guest state itself consists of the guest configuration, x86 runtime configuration, launch metadata and a hash measurement. Part of the initial guest state are the VM save area pages created during the initialization as well as the secrets page, CPUID page and the firmware binaries. Together all these components form the TCB. The table below summarizes the software ingredients of the TCB.
x86 microcode
x86 runtime configuration
SEV-SNP firmware
guest configuration
AMD-SP OS & bootloader
Launch metadata/measurements
Firmware Binaries
VM Save Area page
Secrets page
CPUID page
Other pages as needed
Raw platform attestation is needed whenever a third party or a software needs to have the assurance that workload runs in a CC. Canonical use cases are the live migration of a VM to another platform due to a hardware failure or load balancing mechanisms in the data center where the VM needs to know if at least the current security guarantees are met before allowing the migration to a new platform. Another use case for the raw attestation is the attested secrets provisioning for decrypting the VM storage in order to ensure that the data is still protected after decrypting the image and that the decryption key is protected during the provisioning and decryption phase.
Due to the fact that the hardware is responsible for the measurements adding more and more initial measurements increases the complexity of the TCB which subsequently increases the risk for errors. Additionally if the hardware should be capable to measure the complete stack from the hardware up to the applications the performance will start to degrade a and complete attestation stack is getting less flexible as it is always bound to a specific hardware vendor. To solve the problem of measuring the complete stack different methods need to be utilized.
The Need for stronger TCB integrity
The current method of measuring the firmware, combined with UEFI measured direct boot feature—which uses a hash list—can detect most attacks that occur before the VM boots. However, given that users may entrust highly sensitive data to a Confidential Execution Environment, this alone is insufficient. To address this, the Trusted Computing Base needs to be extended to detect rootkits or unauthorized file manipulations by implementing runtime integrity protection, such as Linux Integrity Measurement Architecture (IMA).
For storing the measurements generated by mechanisms like Linux IMA, secure storage is required to prevent easy manipulation. Typically, this is the role of a Trusted Platform Module (TPM), a specialized microcontroller designed for secure key storage, random number generation, secure storage of platform configurations, and binding all stored data to a hardware-embedded key created during manufacturing. By combining Linux IMA with measured or trusted boot, the TCB becomes even more robust.
The key distinction between measured boot and trusted boot is that trusted boot can halt the boot process if a measurement deviates from a known good value, while measured boot does not. Both approaches can be used alongside Secure Boot. In Secure Boot, all critical boot components must be signed with a private key, and the UEFI firmware stores the corresponding public key. If a component's signature cannot be verified, the boot process is blocked. The initial firmware is assumed to be trusted, as no other component can verify its signature within the Secure Boot chain.
When the system starts, the firmware is measured by the Trusted Platform Module (TPM), and the initial hash is recorded. The firmware then initializes the system and launches the bootloader, which is also measured by the TPM. The bootloader’s hash is combined with the firmware’s hash, creating a chain of measurements. This process continues with the bootloader launching the kernel, which is measured in the same way, and the kernel's hash is combined with the previous measurements.
This chain of measurements can extend to drivers and other components as needed. Once all relevant components have been measured, the user can request an attestation report, signed by the TPM with the final hash, to verify that the recorded measurements match the expected values.
In a cloud-based environment, however, this architecture falls short due to variations in implementation by cloud providers. Typically, a TPM is a specialized and hardened microcontroller designed for the purposes previously discussed. But since cloud providers operate numerous VMs, reserving a physical TPM for each customer, many of whom may never use them, would be inefficient and costly. As a result, TPM functionality is often virtualized through software, resulting in what are known as virtual TPMs (vTPMs).
In scenarios where the cloud provider or hypervisor is trusted, vTPMs are a suitable solution. However, in Confidential Execution Environments (CEE) where the provider or hypervisor is untrusted, vTPMs are unsuitable because the provider could potentially alter the recorded values or access secrets stored in the vTPM.
AMD SEV vTPM-based attestation
Since cloud providers are unlikely to offer hardware TPMs for Confidential Execution Environment enabled VMs, an alternative solution is required. One potential approach is to relocate the vTPM from the hypervisor directly into the guest VM. By doing this, the vTPM benefits from the security guarantees provided by the CEE, removing it from the control of the untrusted hypervisor. However, this introduces a new challenge: the vTPM is now no longer isolated from the untrusted kernel and applications it is meant to measure. This creates a risk, as the kernel or any application could manipulate the vTPM's recorded measurements.
Fortunately, this issue can be addressed by creating an isolated memory region that cannot be accessed by other components. AMD's Virtual Machine Privilege Levels (VMPLs) provide a solution, allowing a VM to divide its software into different privilege levels, similar to x86 rings. The vTPM, along with a lightweight kernel that manages its communication and execution, can be placed in the highest privilege level, VMPL0. The hardware isolation between different VMPLs ensures that less privileged levels cannot access the memory of higher-privileged ones, thereby protecting the integrity of the vTPM.
Running the vTPM as Secure Virtual Machine Service
To launch a virtual machine (VM), a hypervisor like KVM is required to manage tasks such as the initial setup, boot process, and other operations. The VM itself includes the guest operating system and virtualized firmware, such as OVMF.
As illustrated in the image, the Secure Virtual Machine Service Module (SVSM) is a standalone component that communicates with the guest kernel. To handle requests such as device emulation, the SVSM includes a minimal kernel, which implements only the essential functions, such as file systems, scheduling, memory management, and other necessary tasks.
To provide confidential services like a vTPM to the guest OS within the VM, the SVSM requires special privileges, as previously mentioned. The SVSM is loaded into the guest through a two-stage process. The Virtual Machine Manager has been modified to detect the presence of an SVSM binary in the initial firmware image and adjust its launch state, so the SVSM can be loaded first from a non-default address.
SVSM launch process:
Launch the stage 1 loader at a special offset
Move the stage 2 loader from the firmware to the stack base address
Launch the stage 2 loader
Stage 2 loader evaluates the environment and finds a location for the SVSM kernel
Relocate the SVSM kernel from the firmware into a suitable memory location
Launch the SVSM kernel and prepare the VMPL1 pages for the BIOS/UEFI
Once the initial firmware setup is finished, the guest kernel can be launched, potentially at VMPL 1. To communicate with the SVSM, the guest OS kernel must be "enlightened." This means it must be able to detect that it is operating in a specific VMPL and recognize that the SVSM is running at VMPL 0. Furthermore, the guest kernel must support the defined communication protocol for the SVSM to submit requests and receive responses effectively.
COCONUT vTPM SVSM
COCONUT SVSM is currently able to provide an ephemeral vTPM which is protected from the hypervisor as it has been moved into the guest context. In addition the vTPM is protected against manipulation from the guest OS through the usage of the AMD-SEV-SNP VMPL feature. Through the placement of the SVSM in the firmware and including it in the guest initialization stage the SVSM is part of the attestation report and therefore protected against manipulation from the hypervisor.
However the SVSM is currently quite limited as it only includes support for an ephemeral vTPM and no other functionalities. Lately there has been a push to create a persistent state for the SVSM vTPM due to the fact that measurements should be kept across reboots. A first PoC has been created which needs to be further refined until it is ready to be fully implemented. The SVSM is also currently only running on AMD-SEV-SNP enabled platforms. There is ongoing work from Intel to extend the SVSM with Intel TDX support which includes getting the SVSM closer to its goal of being a paravisor which would also enable support for interrupt handling.
Among these bigger challenges that need to be solved there are also other improvements needed for the SVSM like implementing a User-Mode and improving the kernel isolation. Further challenges and plans have been presented at the KVM Forum in 2024.
Last updated
