raghu.nambiar

Introducing Confidential Computing for Private Clouds

Blog Post created by raghu.nambiar Employee on Sep 29, 2020

Securing sensitive data is a high priority for individuals and enterprises. In today’s connected world, there are several points of vulnerability, from your smartphone or laptop, to the internet, intranet and data centers. Throughout these points, there are existing software and hardware solutions that have a goal of protecting data. These include: antivirus software, protecting a system from malware; secure connections which ensure data in transit is encrypted; firewalls which create a barrier between your trusted network and rest of the internet; and data encryption at rest, preventing unauthorized access or theft of data stored on persistent media.

 

Now let’s talk about what confidential computing is all about. Generally speaking, confidential computing is a relatively new concept with a goal to encrypt data in use in the main memory of the system, without compromising on performance.

 

There are two aspects of protecting the data in memory: 1) encrypting full system memory and 2) encrypting individual virtual machine memory and isolating the VM memory from the hypervisor. Full system memory encryption helps defend data against cold boot and even physical attacks. Encrypting individual virtual machine memory helps defend data against attacks originating in other VMs on the same physical host, as well as from the hypervisor itself.

 

Encrypting individual virtual machine memory and isolating it from the hypervisor is critical in today’s highly virtualized, multi-tenant environment.

 

Now let’s talk about how AMD is helping enable confidential computing. One of the key design considerations of the AMD EPYC processors is to provide advanced hardware enabled security features. If customers want to protect the entire system memory, then AMD Secure Memory Encryption (SME) can encrypt system memory with a single key. It’s as simple as enabling a BIOS parameter. In a multi-tenant environment, AMD Secure Encrypted Virtualization (SEV) isolates virtual machines from each other and from the hypervisor. AMD Secure Encrypted Virtualization with Encrypted State (SEV-ES) extends the protection to the CPU registers whose contents are encrypted when a virtual machine stops running.

 

SME, SEV and SEV-ES are part of the AMD Infinity Guardportfolio. The VM security features require enablement in the guest operating system and hypervisor. It is very important to note that AMD’s Secure Encrypted Virtualization helps protect all the applications running on the virtual machine, no code changes or re-compiling of the application are required. If a customer application is running on a system with SEV enabled, then they can reap the benefit of these security features.

AMD and VMware have been working together to enable SEV and SEV-ES on vSphere and we are excited that it is available in vSphere 7.0U1. vSphere 7 is the biggest release of vSphere in over a decade and delivers several innovations including support for AMD’s encrypted virtualization technology. If you are interested in learning more about AMD Secure Encrypted Virtualization (SEV) on VMware ESXi, please attend the on-demand VMware & AMD VMworld panel with Lee Caswell, Rich Brunner, David Dunn and Robert Gomer.

 

We understand the challenges associated with deploying new technologies. To address this we have created an end-to-end configuration guide showing how to set up a confidential computing environment using vSphere and vSAN. The design guide provides step by step instructions to set up a VMware vSAN cluster, build confidential computing virtual machines based on the Linux operating system, and how to deploy applications on it. We have tested popular database and big data benchmarks in order to understand the overhead and performance impact of AMD’s Secure Encrypted Virtualization.

 

AMD engineers ran OLTP and DSS workload tests with and without SEV-ES enabled. Five test runs were performed with the average taken1,2. As shown below, SEV-ES enabled VMs on a VMware ESXi host with a vSAN datastore has a low performance overhead of ~1.4% on OLTP workload and ~6.2% on DSS workload with SQL Server 2019.

 

 

AMD engineers also ran a big data workload test with and without SEV-ES enabled. Five test runs were performed with the average taken1,3. As shown, SEV-ES enabled VMs on a VMware ESXi host with a vSAN datastore has a low performance overhead of ~2% on the big data workload with Apache Hadoop.

 

The configuration described in the guide can be deployed as is or used as a baseline for custom configurations that uniquely address your workload demands. You can access the confidential computing blueprint here

 

I am excited to be a part of the continuing collaboration between AMD and VMware. Together, we are providing customers with a high-performance and security-enhanced virtualization experience for the modern data center.

 

Raghu Nambiar is a Corporate Vice President for AMD. His postings are his own opinions and may not represent AMD’s positions, strategies or opinions. Links to third party sites are provided for convenience and unless explicitly stated, AMD is not responsible for the contents of such linked sites and no endorsement is implied.

 

 

DISCLAIMER

The information contained herein is for informational purposes only and is subject to change without notice. While every precaution has been taken in the preparation of this document, it may contain technical inaccuracies, omissions and typographical errors, and AMD is under no obligation to update or otherwise correct this information. Advanced Micro Devices, Inc. makes no representations or warranties with respect to the accuracy or completeness of the contents of this document, and assumes no liability of any kind, including the implied warranties of noninfringement, merchantability or fitness for particular purposes, with respect to the operation or use of AMD hardware, software or other products described herein. No license, including implied or arising by estoppel, to any intellectual property rights is granted by this document. Terms and limitations applicable to the purchase or use of AMD’s products are as set forth in a signed agreement between the parties or in AMD’s Standard Terms and Conditions of Sale.

2020 Advanced Micro Devices, Inc. All rights reserved. AMD, the AMD Arrow logo, EPYC, and combinations thereof are trademarks of Advanced Micro Devices, Inc. VMware, vSphere, vSAN and ESXi are trademarks or registered trademarks of VMware in the United States and other countries. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Other product names used in this publication are for identification purposes only and may be trademarks of their respective companies.

Footnotes

  1. SEV-ES enabled VMware vSAN cluster Configuration for OLTP and DSS workloads using SQL Server 2019 and Big Data workload using Ambari Hadoop tested with : 4 Hosts each with 1x AMD EPYC 7452, 1TB (16 x 64GB) of RAM, 2x1.6TB NVMe, 6 x 3.2TB NVMe, Broadcom BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller, Mellanox Technologies ConnectX-5 VPI adapter card EDR IB (100Gb/s) and 100GbE dual-port QSFP28 (MCX556A-ECAT) connected to Mellanox SN2410 Ethernet switch 48-port 25GbE + 8-port 100GbE, VMware ESXi 7.0 update 1, VMware vSAN 7.0.1  
  2. System Under Test (SUT) Configuration for OLTP and DSS workloads: VMware Virtual Machine with 32 vCPUs, 768GB of memory, 700GB Hard Disk volume for OS from VMware vSAN, 9TB Hard Disk volume for database from VMware vSAN, uplink to 1GbE NIC, SUSE Linux Enterprise 15 SP2, 5.9.0-rc2-SEV-ES-orig-24.9-default, SQL Server 2019 cu6.  The TPC workloads were driven by HammerDB v3.3 from separate client virtual machine.  SEV-ES feature for Guest OS was enabled for the SUT config labeled as “SEV-ES Enabled” in the Figure 6 and 7.
  3. System Under Test (SUT) Configuration for Big data workload using Hortonworks Data Platform: 8x VMware Virtual Machines each configured with 16 vCPUs, 64GB of memory, 700GB Hard Disk volume for OS from VMware vSAN, 3x1TB Hard Disk volumes for data from VMware vSAN, uplink to 1x1GbE NIC, uplink to 1x100GbE NIC for Ambari Hadoop Cluster,  SUSE Linux Enterprise 15 SP2 5.9.0-rc2-SEV-ES-orig-24.9-default,  HDFS v3.1.1, YARN+MapReduce2 v3.1.1, Zookeeper v3.4.6, Ambari Metrics v0.2.0,  SmartSense 1.5.1.2.7.5.0-72 from Hortonworks Data Platform (HDP) version 3.1.4.  SEV-ES feature for Guest OS was enabled for the SUT config labeled as “SEV-ES Enabled” in the Figure 8.  HDP Cluster used 2 Master Nodes and 6 Data Nodes.

Outcomes