Intel SGX vs AMD SEV - The Ultimate Comparison

Confidential computing is slowly becoming a bigger and more important focus for all global businesses. With the ever expanding cloud, the need for data security and privacy protection, this paradigm has now taken center stage. With a plethora of different potential exploits hiding in hypervisors, host operating systems and even cloud administrators, Intel and AMD have both developed and released their own version of hardware-enforced secure Trusted Execution Environments (TEEs) that can isolate data processing from the rest of the system, ensuring that everything remains encrypted and secure.

These two technologies are SGX (Software Guard Extensions), developed by Intel and SEV (Secure Encrypted Virtualization) by AMD. While both have the same goal of protecting data, they take a very different approach to achieving their aims.

In this article, we are going to take a closer look at both technologies and evaluate how they are structured, how they protect data, their effectiveness and we will also benchmark their performance in order to see how they compare to each other.

What is Intel SGX?

Intel SGX utilizes fine-grained enclaves, which are secure, CPU-protected memory regions that encrypt data. This data is also integrity-checked by the CPU ensuring maximum security. These enclaves can’t be accessed by the OS, hypervisor or any firmware and interactions with these regions are strongly controlled by enclave calls. Not only that, but each one is also cryptographically measured, which ensures that data hasn’t been altered.

In general, this security means that SGX protects from different types of attacks like physical memory snooping, compromised OSes and others, but due to its nature of protection, it doesn’t cover everything, meaning that there could still be some types of attacks like I/O tampering, OS denial of service that can still damage the system.

This makes SGX a good option for security-critical operations like key management and confidential computing.

What is AMD SEV?

AMD SEV by design is a virtual machine confidential computing technology that focuses on protecting whole VMs with the help of its coarse-grained isolation. Throughout recent years SEV has managed to evolve to a very robust technology that went from basic memory encryption with SEV and SEV-ES to a very capable data guard inside of the CPU with SEV-SNP.

SEV focuses on protecting virtual machines from different types of attacks like a hypervisor that has been taken over, physical attacks, register leakages, rollback protection and others. However, it is also susceptible to I/O attacks if additional precautions are not set up. In terms of data integrity verification, also called attestation, it does have a broader coverage than SGX.

In general, SEV can be easily integrated with different virtualization stacks like KVM or QEMU, and is very scalable, delivering security without impacting performance, making it the perfect tool for confidential computing and confidential VMs, which is why we at VPSBG integrate AMD SEV for all of our services.

Intel SGX vs AMD SEV Overview

At a first glance, it would seem that SGX and SEV are very similar, they are actually quite different by design and with the way they solve the confidential computing problem. SGX tries to isolate small code snippets in separate enclaves, whereas SEV isolates the whole virtual machine, meaning that SGX is better focused on application security whereas SEV aims to ensure system and environment security. Here’s a high-level rundown of both technologies and how they fare against each other.

Performance & Usability

When it comes to choosing a confidential computing technology, performance and usability are two of the main factors that are usually considered, which is why we are going to look at some of the most important aspects of both implementations.

CPU & Memory Overhead

Computing is all about speed, which is why we are firstly going to focus on the performance impact of both SGX and SEV. When it comes to SGX, its enclave-focused design impacts performance by nature. Because each enclave has to communicate with the system when it stores, checks or restores a certain CPU state or parameter, each action results in slight overhead that when combined does start to impact performance. Even though there is caching (EPC), its limited size can end up causing huge bottlenecking. This is because once the cache limit is reached, SGX automatically switches to regular RAM, which as you might guess, results in a very drastic performance deterioration with latency spikes and system slowdowns.

On the other hand, SEV’s virtual machine-centric design means that it can offer near-native performance when integrated, with a maximum of 3% overhead for standard workloads. Caching here is much better integrated and memory is encrypted in-line through hardware memory controllers. With SEV-SNP, there are some additional security checks that are carried out in the background, which might sometimes result in some slightly higher overhead, but overall the impact is very non significant.

Because of this, SGX works better when it comes to smaller, compute-targeted operations that don’t exceed the caching limits, whereas SEV manages to keep a very low overhead throughout all operations, making it the more suitable choice for large-scale workloads and applications that require a lot of processing power and memory capacity.

I/O, Networking & Storage

When it comes to storage and operations, SGX strictly divides the enclave code and the OS, which consequently means that all I/O operations must pass through the untrusted boundary first. However, since the enclaves can’t directly make system calls, the data must slowly go in and out of the boundary, causing extra complications like advanced buffer handling and increased serialization overhead. Not only that, but this also expands the surface that potentially be targeted by attackers, resulting in more complexity.

SEV, in comparison, takes care of I/O operations just like a standard virtualized environment, with a paravirtualized interface, which is why performance remains close to native without much overhead. However, even though SEV-SNP does ensure better protection from the hypervisor, it doesn’t completely take care of I/O problems, but in general, SEV’s model helps it avoid much of the complexity that enclaves come with, resulting in a much more transparent workload management.

Multi-Threading & Parallel Workloads

When it comes to parallel workloads, SGX can be quite costly. This is due to the fact that all threads that run inside of the enclaves must operate using the same shared EPC, which as you might guess, further downgrades performance and results in even more bottlenecking.

With SEV, the fact that it acts like a normal virtualized environment without any caching limits means that parallel workloads aren’t really a problem and multi-threading can easily scale across multiple vCPUs without impacting memory or creating any bottlenecks, which makes SEV the go-to technology when it comes to confidential virtual machines.

Intel SGX vs AMD SEV Security

While performance is important, the real reason why such technologies are utilized is to offer security so let’s compare how both handle different threats.

Use Cases

Having covered both SXG and SEV, how they work and what they protect against, it’s now time to look at some use cases and where each technology would make the best fit.

Benchmarks

We’ve talked about the differences between SXG and SEV and what their strengths are with the main point that SXG can be slower when it comes to performance. However, how much slower is SXG actually? We decided to run a lab test environment with an SXG and a SEV-SNP setup in order to evaluate the benchmarks for a more thorough comparison.

Microbenchmark – Cryptographic Operations

Workload: 1,000,000 AES-GCM encrypt operations
Metric: Operations per second

Due to SGX’s need to cross enclave boundaries, it does produce a substantial amount of overhead, going over 60% which can be a problem for applications that require a lot of I/O operations. SEV runs workloads inside a virtual machine, which is why the overhead is very small.

Macrobenchmark – OLTP Database (pgbench)

Workload: 50 clients, mixed read/write, 300-second run
Metric: Transactions per second (TPS)

When it comes to database operations, SGX also shows more than 60% slower results than the native environment, due to the fact that enclave memory and EPC resources are lower, which creates added latency when data has to enter or exit enclaves.

Web/API Benchmark – wrk

Workload: 12 threads, 400 connections, 60 seconds
Metric: Requests per second + latency distribution

Again, the results show much higher ms for SGX due to the limited EPC capacity when having to deal with heavy data loads.

Attestation Time

Metric: Time from application startup to attestation completion and key provisioning

When it comes to attestation, SGX again has a higher time due to the more cryptographically heavy paths, whereas SEV’s attestation time is lower because it is performed as a part of the virtual machine launch.

Overall, Intel SGX has the stronger isolation due to the finer-grained enclaves. However, due to this, SGX also has a substantially higher overhead especially for workloads that involve a large number of system calls or I/O operations. This is because the EPC cache size is very limited and bottlenecks can easily occur with more operations, ultimately making SGX a more suitable choice for smaller workloads, key management and security-critical kernels or crypto-centric actions.

AMD SEV, in comparison, offers near-native performance with minimal slowdown. It does offer coarser-grained isolation as it protects the entire virtual machine from many different types of attacks including from the hypervisor. It scales great, making it an optimal choice for large-memory projects and operations as well as multi-core heavy workloads.