Evolution Of AMD SEV

Security and privacy protection are becoming a luxury that is increasingly sought after in our digital world. With the prominent use of cloud technologies and environments the need to improve cybersecurity has also taken center stage.

In order to tackle these issues, AMD has been working on developing and improving their own technology - Secure Encrypted Virtualization (SEV) in order to enhance the security for virtualized workloads, a technology that we at VPSBG now implement in order to offer secure and privacy-friendly cloud hosting.

But what makes SEV so secure and why is it referred to as a major building block to confidential computing? Join us as we take a tour through the history of SEV and the different stages of its development.

Secure Memory Encryption (SME)

Back when AMD started to look for a way to secure cloud environments, they were first interested in protecting data from unauthorized access, primarily from physical threats that were capable of stealing information from the host server, which is why they first came up with Secure Memory Encryption - SME.

The 2 types of attacks that SME could battle were cold boot and direct memory access attacks. But how did this help? Before SME, data which was stored in the RAM was always exposed and vulnerable to attacks from anyone that had physical access to the machine. This allowed them to extract possibly sensitive information, which could feature anything from encryption keys and passwords to other sensitive data, depending on what was stored on the machine.

With the introduction of SME, full-memory encryption was now possible with the help of a single AES-128 encryption key that was managed by the processor itself. In its essence, it ensures that even if someone were to try and read the contents of the RAM on a given SME-protected machine, they wouldn’t be able to as the data would remain unintelligible even if extracted.

However, while SME was definitely a step in the right direction, it did have its own set of disadvantages, that could still leave room for exploitability. Its most notable drawback is that it only offers one encryption key per system, largely limiting the granular control over security. This, in addition to the fact that it couldn’t protect the host machine from hypervisor-based attacks, due to the lack of isolation between the hosted virtual machines, made it unsuitable for multi-tenant environments.

Secure Encrypted Virtualization (SEV)

The glaring issues of SME when it comes to virtual machines and security, made it clear that improvements were indeed needed, which is why AMD got working on Secure Encrypted Virtualization (SEV).

SEV ultimately expands SME by addressing the issues that we mentioned - it enables per-virtual-machine encryption, effectively isolating each VM from one another and from the hypervisor as well, making it very suitable for cloud computing, virtualization and hosting.

The main issue that it solves is that it prevents hypervisor-based attacks, meaning that even if the hypervisor is compromised, it wouldn’t be able to access any of the virtual machines’ memory due to the fact that they are isolated.

This significantly improves its security and makes SEV a great feature for multi-tenant environments as each virtual machine has its very own encryption key, which prevents other tenants from snooping on each other in the cloud.

SEV expanded SME’s capabilities by enabling per-virtual-machine (VM) encryption, ensuring that each VM has its own unique encryption key, thus isolating VMs from one another and from the hypervisor.

But while SEV did look like the new security standard, it wasn’t long before some other security issues started to arise. While VM memory is encrypted, CPU registers remain exposed, which are also a viable point of entry for those looking to obtain access or information. Additionally, the hypervisor can still modify the state of the virtual machines as well as make changes to the execution of certain commands. Finally, memory integrity was also not verifiable or guaranteed, which meant that certain attacks could still persist.

Secure Encrypted Virtualization with Encrypted State (SEV-ES)

All of these drawbacks forced AMD to continue to make improvements to the technology, which is why SEV with Encrypted State (SEV-ES) was created.

SEV-ES essentially extends SEV by also encrypting CPU register states, ensuring that even if the hypervisor was to be compromised, it would no longer be able to manipulate the register values or be capable of extracting information or make changes to the execution order. This is because SEV-ES encrypts the CPU registers and prevents the hypervisor from injecting malicious values into them, ultimately strengthening VM integrity by dismantling side-channel attacks that rely on changes to the CPU state.

But while one would think that this would bring complete encryption and security to the cloud environment, there are other issues that also needed to be addressed like preventing the hypervisor from making memory modifications, strengthening against replay attacks on memory pages and the issue that was yet to be resolved - memory integrity verification.

Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP)

AMD didn’t waste any time and immediately began working on resolving these issues by introducing SEV with Secure Nested Paging (SNP), which is the protective technology that we at VPSBG implement.

SEV-SNP adds the long awaited memory integrity checks, which also prevent the hypervisor from making changes to guest memory, further encapsulating each virtual machine in the environment. In addition to completely removing the possibility of unauthorized memory modifications, it also prevents rollback attacks, ensuring that the hypervisor cannot tamper with memory contents. This also means that some subtle hypervisor-based attacks are also rendered useless, further ensuring security and encryption, allowing for confidential computing.

And while there is some slight overhead in performance due to the added integrity checks, the security more than compensates for it.

Trusted I/O

The current final stride in AMD’s development focuses on protecting data during I/O operations between virtual machines and external devices like disks, NICs, or GPUs.

SEV-TIO ensures that data moving between VMs and devices is encrypted and that only trusted devices can perform DMA (Direct Memory Access). This prevents malicious peripherals from accessing or tampering with server’s memory. By authenticating devices and encrypting I/O data, SEV-TIO closes a critical security gap in cloud environments, protecting against DMA attacks and unauthorized hardware access.

Overall, it is clear that AMD has come a long way since SME and are actively striving to create a technology that will allow cloud environments to remain security and privacy-friendly, which also aligns with our goals here at VPSBG.