With AMD’s market share slowly increasing, it becomes very interesting to see where EPYC is being deployed. The latest announcement today comes from AMD and Google, with news that Google’s Compute Engine will start to offer new Confidential Virtual Machines (cVMs) built upon AMD’s Secure Encryption Virtualization (SEV) feature. These new cVMs are variants of Google’s N2D series offerings, and Google states that enabling SEV for full memory and virtualization encryption has a near zero performance penalty.

Secure Encryption Virtualization in AMD’s 2nd Gen EPYC processors allows cloud providers to encrypt all the data and memory of a virtual machine at the per-VM level. These are generated on-the-fly in hardware, and are non-exportable, reducing the risk of side attacks by potentially aggressive neighbors. Previously this sort of computing model was only possible if a host assumed control of a whole server, which for most use cases isn’t practical.

With SEV2, technically AMD allows for up to 509 keys per system. Google will offer images for its cVMs with Ubuntu 18.04/20.04, COS v81, and RHEL 8.2; other operating system images will be available in due course.

These cVMs will be available in vCPU listings, confirming that simultaneous multi-threading is enabled on the hardware. Both Google and AMD declined to comment on the exact EPYC CPUs being used, only that they were part of the 2nd Gen Rome family.

This is technically a beta launch, with Google being the first cloud provider to offer SEV-enabled VMs. Google is also promoting the use of its Asylo open-source framework for confidential computing, promising to make deployment easy at a high performance.

A number of 30 MB gifs were created by Google to showcase the new cVMs. Rather than share them with you in an outdated 1989 format, we converted them to video:

Users wanting access to the new VMs should go to the relevant Google page.

Related Reading

POST A COMMENT

20 Comments

View All Comments

  • olafgarten - Tuesday, July 14, 2020 - link

    I wonder why there is a limit of 509 keys, that seems like an arbitrary number. Reply
  • jtd871 - Tuesday, July 14, 2020 - link

    Maybe 512 keys - some number of reserved slots? Reply
  • willis936 - Wednesday, July 15, 2020 - link

    Yes, but why 512? They didn’t want to use more than 9 bits on the index? It isn’t 1977. Reply
  • ravyne - Thursday, July 16, 2020 - link

    I'd wager it's only that large either because there are an equal number of independent hardware blocks doing the encryption/decryption (because that many simultaneous streams at wire-speed isn't going to be software) and/or because that tag needs to be attached to e.g. page table entries and bits are at a premium.

    I'd also guess the 3 tags shy of 512 are reserved for something like unencrypted memory, hypervisor memory, and maybe host-OS memory but more likely for the Intel Management Engine (and AMD equivalent).
    Reply
  • HyperText - Tuesday, July 14, 2020 - link

    It is not the well-rounded 512 keys number because probably around the size of 3 keys (509 + 3 = 512) is needed as overhead to manage the 509 keys. Reply
  • kobblestown - Tuesday, July 14, 2020 - link

    Still, it would be nice to know the exact reason, like 0 being no encryption, 1 encryption for host memory, or sth like that. Is there some gentle introduction to the internals of SEV? Reply
  • Kamen Rider Blade - Tuesday, July 14, 2020 - link

    Maybe 3 of the slots are used for Keys to Encrypt certain parts of Memory to protect itself ahead of time? Reply
  • Dragonstongue - Tuesday, July 14, 2020 - link

    could be a "header" or something along those lines to "give" the 512 total, they start at 509, but if they went say 510 "given keys" after overhead, tags, encryption etc, would end up instead being like 514+ therefore cannot give as many "users" per cluster sort of speak

    seems like this with many things tech wise, 1TB is not the "english" language way of wording, they instead use 1 of 2 methods so the byte/bits add to the 1TB...overhead, have to have page headers or what have you..I always wondered why they just did not make EXACT the number WE expect, even if this meant cramming extra on or some crud...

    but that is "tech" for you, coding and all that, for me and you 1+1=2, but with fancy computer crud, it likely breaks the nice mold, much like that 1GHZ CPU is more or less NEVER to run exact this way..

    word games, not knowing the reason for the reason sucks either way ^.^
    Reply
  • avbohemen - Tuesday, July 14, 2020 - link

    In the video, the CPU used is an AMD EPYC 7B12 (family: 0x17, model: 0x31, stepping: 0x0) You can see that 3 seconds from the end. Reply
  • brucethemoose - Tuesday, July 14, 2020 - link

    "A number of 30 MB gifs were created by Google to showcase the new cVMs. Rather than share them with you in an outdated 1989 format, we converted them to video"

    Hah, even Google has given up on webp.

    I can't wait until AVIF(S) is a widely supported thing.
    Reply

Log in

Don't have an account? Sign up now