14 ms·

Confidential VMs

181 points by caution 6y ago

zimmerfrei 6y ago
This is using SEV-ES (SEV2) which is vulnerable to the severe attack described last year in [1], and unfixable due to the lack of antirollback functionality. Only SEV-SNP [2] is supposed to address it, but only on new silicon which doesn't exist yet, and that probably not even Google has. So why is Google releasing this feature if it is so flawed? [1] https://arxiv.org/pdf/1908.11680.pdf https://arxiv.org/pdf/1908.11680.pdf [2] https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthen...
- zimmerfrei 6y ago
  Even worse: according to a source of The Register [1], it is based on simple SEV (SEV1), not even SEV-ES. If true, it is even more disappointing. [1] https://www.theregister.com/2020/07/14/google_amd_secure_vm/ https://www.theregister.com/2020/07/14/google_amd_secure_vm/
mfer 6y ago
> Confidential VMs leverage the Secure Encrypted Virtualization (SEV) feature of 2nd Gen AMD EPYC™ CPUs Powered by AMD. I wonder who will leverage this next.
bec123 6y ago
If your data is sensitive you should not be sharing resources (cores/memory) with other users, IMO.
- dijit 6y ago
  I am the first person to agree with you, without hesitation. But it’s worth looking at exactly what it means to attempt isolation of programs on shared hardware. SEV is an interesting way of working on it. It seems pretty clear that your data could never be modified or read, but there’s nothing preventing starvation of resources or side-channel attacks to leak encrypted values. Of course I also always argue against using the cloud for anything sensitive as “the cloud is really, just someone else’s computers”. Albeit with a fancy provisioning api and some proprietary services adjoining it.
  - caymanjim 6y ago
    I question the limits of security in cloud services, but there's more to it than the technical aspects. There's a component of CYA for regulatory compliance. If you're a financial or medical company, you've got to demonstrate a good-faith effort to implement various thresholds of security to pass e.g. SOC audits, and this helps. Nothing is 100% secure. This is a component of an overall security plan. I don't want to overstate the benefit, but it's more than just PR.
  - acdha 6y ago
    > Of course I also always argue against using the cloud for anything sensitive as “the cloud is really, just someone else’s computers”. This is too simplistic: employing that argument obligates you to show how you’re mitigating the same threats on your own, especially with regards to ops and security staffing. I have considerably more confidence in any major cloud provider having robust internal monitoring than the typical corporate VMware deployment, and that even extends to bare metal unless you can air-gap it — if you get a bare metal server from AWS, Azure, Google, etc. they’ve still put more work into the firmware, management interfaces, etc. than most IT groups do and those are very juicy attack surfaces.
    - dijit 6y ago
      This conversation will become quickly fruitless because everyone is different levels of risk averse. For me, I can say plainly: "this piece of equipment has these access controls, both physical and virtual and we have various radio frequency dampening systems" etc; For you, you can think about outsourcing that responsibility. There's no "right" answer, some cloud providers may indeed have much stricter access controls than I could ever have (for instance, budgets may require my servers to exist in a physically shared space, albeit in my own racks; those racks being porous to allow airflow). But ultimately you will never have more control than if you have complete ownership and audit capability of all systems. I'm sure many people have lived in the same regulatory hell that I have; and I wouldn't argue that the regulatory hell is easier in the cloud or otherwise; I would instead argue that if I was the CIO; I would sleep better knowing I had done my job and not attempted to outsource the responsibility and wash my hands of it, which is what you're effectively doing, even if you trust the cloud provider, even if they've shown good faith- it's no longer your eminent domain to oversee.
- jacobush 6y ago
  Most things fall on a spectrum - I view this as an iterative enhancement.
- doublerabbit 6y ago
  And that's why I colocate my servers.
  - nix23 6y ago
    >And that's why I colocate my servers. And its often cheaper has better performance and no lock-in to a cloud provider.
  - theevilsharpie 6y ago
    There's an entire ecosystem of supported services in GCP (or whatever cloud provided you'd be passing on) that you would have to find an alternative for if you want to co-locate and manage your own physical equipment. The more logical alternative (without abandoning the cloud entirely) would be to use the cloud provider's dedicated instance functionality (GCP's terminology for this is "sole-tenant nodes"), but these are much more expensive than virtual machine instances, especially if you don't need the capacity of a dedicated node. At some point, you or your bosses are going to be asking if the security is _really_ worth the premium. SEV-enabled VMs can provide a convenient middle ground -- more protection than just a hosted VM instance, but since you're still sharing physical resources, the cost is closer to a VM than a dedicated instance. If SEV VMs are considered the equivalent of dedicated instances from a compliance perspective, this could open the door to cloud hosting for a variety of industries who were unable to do shared hosting before. However, that if remains to be seen.
    - Spivak 6y ago
      Having worked at companies that colo'd and ran on AWS I think the difference isn't as big as you're making it seem. Many of services you "need" in the cloud are only needed because you're in a cloud in the first place. The good news about colo'd equipment is that it's dirt cheap. You can have millions of customers running on a few poweredge nodes with full redundancy and capacity to spare.
      - theevilsharpie 6y ago
        > You can have millions of customers running on a few poweredge nodes with full redundancy and capacity to spare. As someone that actually manages "a few PowerEdge nodes," you're overstating their capability and oversimplifying what it takes to run a production-grade system with millions of users.
maayank 6y ago
How is SEV compared to SGX?
- nix23 6y ago
  SEV is atm considered 'secure' SGX is not: https://arstechnica.com/information-technology/2020/03/hackers-can-steal-secret-data-stored-in-intels-sgx-secure-enclave/ https://arstechnica.com/information-technology/2020/03/hacke...
  - als0 6y ago
    Not at all. SEV has been broken many times and by more trivial means [1-3] [1] https://arxiv.org/pdf/1805.09604.pdf https://arxiv.org/pdf/1805.09604.pdf [2] https://regmedia.co.uk/2019/07/10/amd.pdf https://regmedia.co.uk/2019/07/10/amd.pdf [3] https://www.theregister.com/2019/06/26/amd_epyc_key_security_flaw/ https://www.theregister.com/2019/06/26/amd_epyc_key_security...
    - benlivengood 6y ago
      The two attack vectors are page table integrity and unencrypted VM state. Modifying the page tables to establish a cryptographic merkle tree would fix the first attack, and SEV-ES fixes the secrecy attack from the second paper. Unfortunately a change to page table structure may make it impossible to run unmodified kernels in the VM. I think it as impossible to prevent a hypervisor from fingerprinting what's running on a child VM; there are too many timing and power attacks to ever mitigate that, which was the attack vector on SEV-ES
- nellydpa 6y ago
  SEV: No changes are required to the apps, better performance, but bigger TCB. GCP mitigate this with Shielded VMs, in particular integrity of the kernel in your trusted boundary, notifications to users if the integrity state changed from the baseline and made it default and free. https://cloud.google.com/blog/products/identity-security/security-simplified-making-shielded-vm-default-compute-engine https://cloud.google.com/blog/products/identity-security/sec... SGX: smaller TCB, but limited scale, and you have to partition your app to secure and no-secure parts using one of the SDK available, Intel SGX SDK, Microsoft OpenEnclave or Google Asylo.
rwmj 6y ago
Is SEV really a "breakthrough technology"? AMD was far from the first to do this, and you have to trust AMD to have implemented this correctly and not be backdoored or cooperating with the US government to believe it's really secure.
- tyingq 6y ago
  They are ahead of Intel, at least. In the server/VM market, that is roughly the same as being first...at least for now.
- theevilsharpie 6y ago
  > Is SEV really a "breakthrough technology"? SEV is a breakthrough in the sense that it's essentially transparent to the guest environment. Earlier technologies like Intel SGX or ARM TrustZone have a lot of performance limitations, and application needs to be explicitly developed to support it. Intel is working on a similar technology -- Total Memory Encryption (TME) -- but they haven't released it to market yet.
  - thu2111 6y ago
    Intel actually had a similar tech without the RAM encryption some time ago, called TXT. TXT never really took off. There were a few problems, but, I don't think SEV has actually solved these problems, beyond the lack of the memory encryption. One is that the hypervisor is ... well it's still a hypervisor. It can play a lot of games on the operating system, and hardware is limited in what it can do to stop that. TXT's solution was to "measure" the hypervisor, so you could audit it. That doesn't work for google/aws/azure who all use proprietary hypervisors, so you need to place a lot of trust in your chip and kernel that they can resist arbitrary malicious behaviour by the most privileged piece of software on the system - one that controls all hardware access. That's very difficult. For instance, the hypervisor controls access to the system clock. Another is that it was very hard to make the operating system secure. Heartbleed being just one example of what can go wrong. So the trusted computing community concluded around this time that placing an entire operating system into your 'trusted computing base' doesn't really work. It's trying to run before you can walk. If you can't make the operating system reliably secure against remote attackers then trying to make it secure against the far harder adversary of someone who controls your hardware stack seems futile. That's why Intel's equivalent isn't transparent. It's not very opaque, it's basically like loading a shared library and the library gets encrypted RAM. But when you try to write an enclave that's really secure, you realise that there's a lot the host machine can do to make a mess of things. I don't think that changes much if it's "just" the hypervisor that's malicious instead of the hypervisor and kernel. The solutions end up looking the same - you want to minimise your attack surface, you need to think carefully about clocks and time sequencing, side channel attacks, etc.
I_am_tiberius 6y ago
I guess a database as a service instance at Google will still be accessible for Google in a decrypted way?
- nellydpa 6y ago
  Unless you run a database in the Confidential VM, can run mySQL, postgresql, MariaDB. Google managed db service, say GCP CloudSQL is not supported...
kop316 6y ago
Does anyone know what mode of AES that SEV (or SME) uses? I have been reading though all of AMD's documents, and I cannot find what mode of AES that SEV (or SME) uses. I find it extremely odd that this is not called out in any of AMD's documents, and frankly a bit worrisome. For the record, "A Comparison Study of Intel SGX and AMD Memory Encryption" [1] claims a modified version of AES-ECB is what SEV uses, BUT their reference links to AMD's whitepaper [2], which does NOT say anything about their mode, so I do not consider [1] to be a trustworty resouce. [1] https://caslab.csl.yale.edu/workshops/hasp2018/HASP18_a9-mofrad_slides.pdf https://caslab.csl.yale.edu/workshops/hasp2018/HASP18_a9-mof... [2] https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf https://developer.amd.com/wordpress/media/2013/12/AMD_Memory...
- nellydpa 6y ago
  The answer to your question: The AES mode AMD SEV uses is similar to XEX. AMD computes a tweak value based on the physical memory address and performs an xor-encrypt-xor operation. The tweak algorithm used on Rome (2nd gen EPYC) is based on GF math and uses a random value that is changed on each boot.
- tux3 6y ago
  They document a "physical address based tweak". My understanding is that this is xoring a function of the physical address with each 128bit block before going into AES-ECB (and that function is that same for every VM on your system).
  - kop316 6y ago
    I only saw that in "A Comparison Study of Intel SGX and AMD Memory Encryption", which per my grandparent comment, is not a trustworthy source (they reference the whitepaper, and the whitepaper doesn't say anything about it). Is that documented in an actual AMD source, or even talk?
    - tux3 6y ago
      As far as I know, the whitepaper is all you will find publicly. It does mention the tweak (on page 4), only if you want the details and don't trust the third-party papers, you will have to reverse-engineer that yourself =]
blickentwapft 6y ago
I kind of assumed all my cloud computing resources were already private and confidential. Not so?
- jagged-chisel 6y ago
  Do you mean those resources physically located with you? That's a good assumption. Or do you mean those resources physically located in someone else's data center running on their hardware and software platforms among their infrastructure and only assigned to your task as-needed? That's a bad assumption.
  - deleted 6y ago
    [deleted]
- kanobo 6y ago
  Data in cloud and probably on the device you're using right now is mainly only encrypted while sitting on the disk and when bouncing around the net. The difference here is that the data is also encrypted throughout its life - while in memory and while the data is getting processed on the machine.
- nellydpa 6y ago
  You are right, data is private and confidential when it is ingested to the cloud and/or stored in the cloud, not when processed. Encryption of "data-in-use" is the 3rd leg in data protection of sensitive data, and it became possible with hw capabilities in new CPU chipsets, from AMD and Intel, as it has to be hardware based (better security and performance).
  - thu2111 6y ago
    As storage and ingestion requires processing, that's the same as saying it's not private at any point when in the cloud. And that's not necessarily a big deal. If you trust Google or AWS to hold all your business and customer data, no problem (and if your customers transitively have that trust). But I think there's a lot of denial about this fact: the cloud has all your data and all your customers data. Fixing that is really, really hard. It's not anywhere near as simple as Google are claiming in this announcement, certainly not "tick a box and it's switched on".
nemothekid 6y ago
Is this homomorphic encryption or something else?
- nellydpa 6y ago
  Homomorphic encryption enables computation to be performed on encrypted data without the need to decrypt it on the CPU. Compared to Confidential Computing approaches, the processing complexity of FHE is quite high, especially for tasks that require execution of complicated algorithms, making it hard to scale with this approach. Confidential VMs with AMD SEV decrypt data within VMs and keep it encrypted "in-use" by encrypting memory with a key generated by AMD secure processor (non-extractable) per VM. After processing data and code can be encrypted back to keep it protected at-rest.
  - MereInterest 6y ago
    I don't understand, and couldn't get any information from the article either. If the data are decrypted within the VM, then it is still decrypted at that point, and the host machine can read it.
    - theevilsharpie 6y ago
      The data is transparently encrypted and decrypted specifically within the processor. The OS kernel on the host machine doesn't have access to the unencrypted contents of the guest VM's memory. > I don't understand, and couldn't get any information from the article either. See this wiki article for more info on this class of technology: https://en.wikipedia.org/wiki/Data_in_use https://en.wikipedia.org/wiki/Data_in_use
    - nellydpa 6y ago
      You can access memory within a VM, not outside of a VM. Host machine with a hypervisor is not within a VM instance, so it will not be able to read your VM memory. The memory is encrypted all the time, but when the instruction has to be executed on CPU, memory controllers (only and only have access to the keys of this VM) decrypt the instruction to execute it on cpu in clear. For FHE, cpu instructions are executed on AES encrypted blocks, and will take significant time, so not very practical today. Does it make sense?
Dyaz17 6y ago
What is the attack Vector that this solution prevent ? Am I missing something obvious ? Will it prevent Google from being able to have a Root access to the VM? From my understanding it does not seem to protect from Google. If they are still able to have a Root Access to the VM it does not matter if the memory is encrypted or not. The only thing that I see, is in case of a spectre/meltdown vulnerabilty where the isolation of the RAM fails...
- nellydpa 6y ago
  GCP does not have root access to the customers VMs. Confidential VMs with AMD SEV create an additional cryptographic isolation layer (in addition to virtualization one) between tenants and Google infra, mitigate 0days guest escapes, make observability attacks less possible, protect against some set of DMA attacks, and mitigate memory physical access attacks. To add to this not all spectre variants are applicable to AMD SEV, e.g. L1TF or foreshadow is not.
  - derefr 6y ago
    > GCP does not have root access to the customers VMs I mean, they have physical access to the hypervisor host machines, where they could do anything they like to them, e.g. tap the JTAG pins of the CPU. Insofar as you assume that the attack here is “the NSA compels Google to gather evidence against you”, the lack of just being able to log into the VM doesn’t really change much.
    - asah 6y ago
      This protects against remote rogue employees and intruders. As for physical attacks, Google is ultra paranoid about physical access to DCs, and I think we can quickly agree that rogue employees and outsiders would have little chance of successful attack given the outrageous (and secret) methods that Google employs. Remember, this is one of the most-attacked organizations in the world, they've had decades (plural) to enact defenses and test them, and a successful attack would cost them over $10 billion - there's a virtually unlimited budget for physical defense. Circa 2020, I'd put Google's physical intrusion defenses up against most military installations.
hlandau 6y ago
May as well note: SEV relies on AMD-signed vendor firmware blobs. This means that AMD, or anyone who can get their keys, can compromise the security of SEV.
- nellydpa 6y ago
  Actually, the integrity of the AMD microcode can be verified using Google stackdriver as part of VM audit logs, together with the integrity of the VM kernel.
gchokov 6y ago
This is a terrible name. Assume everything else is not confidential!
- nellydpa 6y ago
  But everything else is not actually confidential... Confidentiality means limited visibility, when you process your data, the memory is in clear without this tech, or Intel SGX that offer confidentiality and integrity.
eloff 6y ago
So what does SEV actually protect against? Something like heartbleed would still happily decrypt and transmit confidential data. Something like speculative side channel attacks would still speculate on the unencrypted memory right? Rowhammer would still flip bits, but now one bit flipping would turn an entire 128 bit block into garbage when decrypted? It seems like that would at least make rowhammer a lot harder to exploit into a privilege escalation. ECC memory already gave some limited protection here.
- theevilsharpie 6y ago
  > Something like speculative side channel attacks would still speculate on the unencrypted memory right? This wouldn't prevent a Spectre attack or similar cache-based attack, as the memory would be decrypted at that point. However, it would mitigate attacks like Meltdown or Rowhammer.
  - eloff 6y ago
    I don't see how it protects against meltdown, wouldn't the memory still get decrypted by the escalated access? Edit: If each VM has it's own key, then they couldn't read each other's memory with meltdown. I think that must be the angle.
    - theevilsharpie 6y ago
      > I don't see how it protects against meltdown, wouldn't the memory still get decrypted by the escalated access? No. A particular VM's memory is decrypted by that VM's key. Assuming that AMD's CPUs were vulnerable to a hypothetical attack similar to Meltdown, either a VM or a guest would be able to dump the machine's memory, but the memory contents belonging to other VMs would be encrypted and unintelligible.
      - eloff 6y ago
        I think my edit and your comment passed each other on the wire. That makes sense, it gives hardware protection from privilege escalation between VMs on the same host. Be it through a hardware exploit or hypervisor vulnerability.
Illniyar 6y ago
Is there demand for such a thing? I mean what is the use case where one would want this level of security.
- nellydpa 6y ago
  Quite a few: protect sensitive data in the cloud from the tenants and cloud providers, protect my clients sensitive data, address some requirements of the regulated markets, mitigate some privacy regulations, and a few new: collaborative computing with untrusted parties?
dsr_ 6y ago
Technology, technology, blah blah blah. Tell me this: will Google indemnify you against all your losses proportional to the amount they are to blame? i.e. if you lose $50 million because you relied on Google's "confidential VM" and an investigation shows it's 100% because Google didn't protect the VM, do you get a year's worth of fees back or $50MM?
- occamrazor 6y ago
  The SLA normally covers only the cost of running the VM, or a small multiple thereof. You can negotiate a better SLA, but you’re unlikely to get it. A better alternative is insurance. There are many insurers that offer contingent business interruption coverage for failure of cloud infrastructure, among other causes.
- panarky 6y ago
  Will the bank indemnify you against all your losses if a thief breaks into your safe deposit box?
- sl1ck731 6y ago
  I've been thinking about this in regard to AWS. The encryption at rest for most things is completely transparent so the only thing your really protected against is someone walking into a data center and grabbing your drive somehow. Or improperly disposed drives. Maybe some kind of hypervisor or SAN exploit but I don't know much about that. AWS seems to have turned part of the cloud operating model they are supposed to be responsible for back onto the user and no one questions it.
  - WrtCdEvrydy 6y ago
    Sorry, here's your cloud fees back.
    - ape4 6y ago
      Self hosting (remember that) seems best for really confidential things.
josephcsible 6y ago
I don't like this technology. If it works as claimed, it could be used for almost unbreakable DRM.
- theevilsharpie 6y ago
  It already has been in a sense, as the underlying technology for SEV was developed by AMD to protect the DRM running on game consoles. That being said, AMD SEV is transparent to the underlying applications and users, so anyone with an interest in protecting memory from certain classes of attacks (e.g., Meltdown, Rowhammer) can benefit. Other technology in this space (e.g., Intel SGX, Arm TrustZone) requires the application to explicitly support the secure enclave, so their usefulness to a typical end-user is much more limited, and as such, they aren't really used much other than to enable DRM.
deleted 6y ago
[deleted]
2dvisio 6y ago
This seems a move to make people handling sensitive data (E.g. healthcare and insurance) make sure they have peace of mind and can tick the box “security and privacy” off? Even neutralising the potential issue of being linked with the omniscient google? How will MS and AWS respond will be interesting.
- theevilsharpie 6y ago
  Confidential VM is essentially productizing AMD SEV technology. Intel will have something similar on the market in the (hopefully near) future. Given that AWS and Azure also use AMD and Intel equipment, I'd expect them to introduce similar functionality. (AWS is probably closer as SEV support is built into Linux, whereas Windows has no support for it as far as I can tell.)
als0 6y ago
It's interesting that there's no mention of Intel SGX in this blog post.
- theevilsharpie 6y ago
  It doesn't use Intel SGX, nor would SGX work with such a service. Intel is working on a competing technology -- Total Memory Encryption -- but AMD beat them to market by quite a bit.
mtgx 6y ago
Couldn't Signal use this, too? I know they use the more limited SGX now.
yasoob 6y ago
They state in the press release: > With the beta launch of Confidential VMs, we’re the first major cloud provider to offer this level of security and isolation while giving customers a simple, easy-to-use option for newly built as well as “lift and shift” applications. How is Google's offering different from the Confidential Compute Microsoft already offers?[1] [1] https://azure.microsoft.com/en-us/solutions/confidential-compute/ https://azure.microsoft.com/en-us/solutions/confidential-com...
- saagarjha 6y ago
  This uses AMD's SVE, which as I understand is more akin to Intel's MPX than SGX (which is what Microsoft is using).
  - deleted 6y ago
    [deleted]
  - theevilsharpie 6y ago
    The equivalent Intel technology is TME, which is not present in any commercially-available processor yet. MPX was an instruction extension that was never widely adopted and that Intel has deprecated.
- strstr 6y ago
  SGX has a stronger security model, but targets enclaves instead of VMs. If you want something to run in SGX, you will likely need to rewrite the software (you can’t call syscalls directly in SGX since you cannot trust their results anyway). SEV’s security model is weaker (no integrity), but lets you use essentially normal VM images. Disclaimer: I work at Google in this space.
- Uptrenda 6y ago
  The Microsoft solution uses Intel SGX and all it gives you is access to a machine that has an SGX-enabled processor with some SDK tools pre-installed to use it. The SDK is C-based and reimplements parts of the C standard library -- having non-standard arguments and return types in some cases (like say unsigned instead of signed.) In this case: you have to write all the code yourself and manage the secure processor features to use it. It's application-level, same host / OS. Googles offering is more intuitive. Google Cloud already stores data on VMs encrypted to disk and handles decryption to be able to start the VM. But once the data is in memory its unencrypted and could be read by other processes. On a bare metal machine there may be more than one VM using portions of the same processor with physical access to the same memory range. So compromising this at a higher level would effect other customers. With the new offering it supports encrypted memory isolation for a virtualised VM. It's on a VM-level or 'whole operating system' meaning there is no need to write any special code to take advantage. You just tick a box. Tech is by AMD and not Intel. Both of these options support different use-cases, IMO. Microsofts confidential compute allows you to manage untrusted applications on the same host with a high level of control. You can prove to other machines running the same app that you're doing this 'securely.' The Google solution doesn't give you the same level of granularity but is much, much easier to use for those who just want to take advantage of better memory protection and integrity checks. My thoughts on this are mixed though because: 1. While the products are clearly very different -- Intel's SGX tech has already had numerous security vulnerabilities and that doesn't make me very optimistic AMD will have magically solved those issues. 2. The general advice in finance for highly sensitive data is not to use VMs, period. Since privilege escalation on one VM could potentially lead to access to the bare metal and hence access to the other VMs. Some of these risks still seem relevant even if memory protection is being used. I.E. it's better not to use VMs if you care about security. Trying to attract more highly sensitive data to 'the cloud' makes me nervous, to be honest. 3. I like the concept in general. Even though it's not a silver bullet it's nice to be able to have access to this option.
algorithm314 6y ago
It is funny that Kubernetes,Istio, Asylo etc are transliteration of greek words and Google has trademarks on them.
cperciva 6y ago
Confidential Computing environments keep data encrypted in memory and elsewhere outside the central processing unit (CPU). Aren't Amazon's Graviton 2 processors specified to do this too?
- theevilsharpie 6y ago
  My knowledge of Graviton is limited, but based on Amazon's description of Graviton 2's encryption capabilities, it seems more like an equivalent to AMD's Secure Memory Encryption (SME), rather than SEV.
  - ENOTTY 6y ago
    It's a lot more than just a SME equivalent. They've designed the management plane in a really clever way that makes it more similar to SGX/SEV than at first glance. I recommend watching this video https://www.youtube.com/watch?v=kN9XcFp5vUM https://www.youtube.com/watch?v=kN9XcFp5vUM

181 points by caution 6y ago

This is using SEV-ES (SEV2) which is vulnerable to the severe attack described last year in [1], and unfixable due to the lack of antirollback functionality. Only SEV-SNP [2] is supposed to address it, but only on new silicon which doesn't exist yet, and that probably not even Google has. So why is Google releasing this feature if it is so flawed? [1] https://arxiv.org/pdf/1908.11680.pdf https://arxiv.org/pdf/1908.11680.pdf [2] https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthen...

zimmerfrei 6y ago
Even worse: according to a source of The Register [1], it is based on simple SEV (SEV1), not even SEV-ES. If true, it is even more disappointing. [1] https://www.theregister.com/2020/07/14/google_amd_secure_vm/ https://www.theregister.com/2020/07/14/google_amd_secure_vm/

mfer 6y ago

> Confidential VMs leverage the Secure Encrypted Virtualization (SEV) feature of 2nd Gen AMD EPYC™ CPUs Powered by AMD. I wonder who will leverage this next.

bec123 6y ago

If your data is sensitive you should not be sharing resources (cores/memory) with other users, IMO.

dijit 6y ago
I am the first person to agree with you, without hesitation. But it’s worth looking at exactly what it means to attempt isolation of programs on shared hardware. SEV is an interesting way of working on it. It seems pretty clear that your data could never be modified or read, but there’s nothing preventing starvation of resources or side-channel attacks to leak encrypted values. Of course I also always argue against using the cloud for anything sensitive as “the cloud is really, just someone else’s computers”. Albeit with a fancy provisioning api and some proprietary services adjoining it.
- caymanjim 6y ago
  I question the limits of security in cloud services, but there's more to it than the technical aspects. There's a component of CYA for regulatory compliance. If you're a financial or medical company, you've got to demonstrate a good-faith effort to implement various thresholds of security to pass e.g. SOC audits, and this helps. Nothing is 100% secure. This is a component of an overall security plan. I don't want to overstate the benefit, but it's more than just PR.
- acdha 6y ago
  > Of course I also always argue against using the cloud for anything sensitive as “the cloud is really, just someone else’s computers”. This is too simplistic: employing that argument obligates you to show how you’re mitigating the same threats on your own, especially with regards to ops and security staffing. I have considerably more confidence in any major cloud provider having robust internal monitoring than the typical corporate VMware deployment, and that even extends to bare metal unless you can air-gap it — if you get a bare metal server from AWS, Azure, Google, etc. they’ve still put more work into the firmware, management interfaces, etc. than most IT groups do and those are very juicy attack surfaces.
  - dijit 6y ago
    This conversation will become quickly fruitless because everyone is different levels of risk averse. For me, I can say plainly: "this piece of equipment has these access controls, both physical and virtual and we have various radio frequency dampening systems" etc; For you, you can think about outsourcing that responsibility. There's no "right" answer, some cloud providers may indeed have much stricter access controls than I could ever have (for instance, budgets may require my servers to exist in a physically shared space, albeit in my own racks; those racks being porous to allow airflow). But ultimately you will never have more control than if you have complete ownership and audit capability of all systems. I'm sure many people have lived in the same regulatory hell that I have; and I wouldn't argue that the regulatory hell is easier in the cloud or otherwise; I would instead argue that if I was the CIO; I would sleep better knowing I had done my job and not attempted to outsource the responsibility and wash my hands of it, which is what you're effectively doing, even if you trust the cloud provider, even if they've shown good faith- it's no longer your eminent domain to oversee.
jacobush 6y ago
Most things fall on a spectrum - I view this as an iterative enhancement.
doublerabbit 6y ago
And that's why I colocate my servers.
- nix23 6y ago
  >And that's why I colocate my servers. And its often cheaper has better performance and no lock-in to a cloud provider.
- theevilsharpie 6y ago
  There's an entire ecosystem of supported services in GCP (or whatever cloud provided you'd be passing on) that you would have to find an alternative for if you want to co-locate and manage your own physical equipment. The more logical alternative (without abandoning the cloud entirely) would be to use the cloud provider's dedicated instance functionality (GCP's terminology for this is "sole-tenant nodes"), but these are much more expensive than virtual machine instances, especially if you don't need the capacity of a dedicated node. At some point, you or your bosses are going to be asking if the security is _really_ worth the premium. SEV-enabled VMs can provide a convenient middle ground -- more protection than just a hosted VM instance, but since you're still sharing physical resources, the cost is closer to a VM than a dedicated instance. If SEV VMs are considered the equivalent of dedicated instances from a compliance perspective, this could open the door to cloud hosting for a variety of industries who were unable to do shared hosting before. However, that if remains to be seen.
  - Spivak 6y ago
    Having worked at companies that colo'd and ran on AWS I think the difference isn't as big as you're making it seem. Many of services you "need" in the cloud are only needed because you're in a cloud in the first place. The good news about colo'd equipment is that it's dirt cheap. You can have millions of customers running on a few poweredge nodes with full redundancy and capacity to spare.
    - theevilsharpie 6y ago
      > You can have millions of customers running on a few poweredge nodes with full redundancy and capacity to spare. As someone that actually manages "a few PowerEdge nodes," you're overstating their capability and oversimplifying what it takes to run a production-grade system with millions of users.

maayank 6y ago

How is SEV compared to SGX?

nix23 6y ago
SEV is atm considered 'secure' SGX is not: https://arstechnica.com/information-technology/2020/03/hackers-can-steal-secret-data-stored-in-intels-sgx-secure-enclave/ https://arstechnica.com/information-technology/2020/03/hacke...
- als0 6y ago
  Not at all. SEV has been broken many times and by more trivial means [1-3] [1] https://arxiv.org/pdf/1805.09604.pdf https://arxiv.org/pdf/1805.09604.pdf [2] https://regmedia.co.uk/2019/07/10/amd.pdf https://regmedia.co.uk/2019/07/10/amd.pdf [3] https://www.theregister.com/2019/06/26/amd_epyc_key_security_flaw/ https://www.theregister.com/2019/06/26/amd_epyc_key_security...
  - benlivengood 6y ago
    The two attack vectors are page table integrity and unencrypted VM state. Modifying the page tables to establish a cryptographic merkle tree would fix the first attack, and SEV-ES fixes the secrecy attack from the second paper. Unfortunately a change to page table structure may make it impossible to run unmodified kernels in the VM. I think it as impossible to prevent a hypervisor from fingerprinting what's running on a child VM; there are too many timing and power attacks to ever mitigate that, which was the attack vector on SEV-ES
nellydpa 6y ago
SEV: No changes are required to the apps, better performance, but bigger TCB. GCP mitigate this with Shielded VMs, in particular integrity of the kernel in your trusted boundary, notifications to users if the integrity state changed from the baseline and made it default and free. https://cloud.google.com/blog/products/identity-security/security-simplified-making-shielded-vm-default-compute-engine https://cloud.google.com/blog/products/identity-security/sec... SGX: smaller TCB, but limited scale, and you have to partition your app to secure and no-secure parts using one of the SDK available, Intel SGX SDK, Microsoft OpenEnclave or Google Asylo.

rwmj 6y ago

Is SEV really a "breakthrough technology"? AMD was far from the first to do this, and you have to trust AMD to have implemented this correctly and not be backdoored or cooperating with the US government to believe it's really secure.

tyingq 6y ago
They are ahead of Intel, at least. In the server/VM market, that is roughly the same as being first...at least for now.
theevilsharpie 6y ago
> Is SEV really a "breakthrough technology"? SEV is a breakthrough in the sense that it's essentially transparent to the guest environment. Earlier technologies like Intel SGX or ARM TrustZone have a lot of performance limitations, and application needs to be explicitly developed to support it. Intel is working on a similar technology -- Total Memory Encryption (TME) -- but they haven't released it to market yet.
- thu2111 6y ago
  Intel actually had a similar tech without the RAM encryption some time ago, called TXT. TXT never really took off. There were a few problems, but, I don't think SEV has actually solved these problems, beyond the lack of the memory encryption. One is that the hypervisor is ... well it's still a hypervisor. It can play a lot of games on the operating system, and hardware is limited in what it can do to stop that. TXT's solution was to "measure" the hypervisor, so you could audit it. That doesn't work for google/aws/azure who all use proprietary hypervisors, so you need to place a lot of trust in your chip and kernel that they can resist arbitrary malicious behaviour by the most privileged piece of software on the system - one that controls all hardware access. That's very difficult. For instance, the hypervisor controls access to the system clock. Another is that it was very hard to make the operating system secure. Heartbleed being just one example of what can go wrong. So the trusted computing community concluded around this time that placing an entire operating system into your 'trusted computing base' doesn't really work. It's trying to run before you can walk. If you can't make the operating system reliably secure against remote attackers then trying to make it secure against the far harder adversary of someone who controls your hardware stack seems futile. That's why Intel's equivalent isn't transparent. It's not very opaque, it's basically like loading a shared library and the library gets encrypted RAM. But when you try to write an enclave that's really secure, you realise that there's a lot the host machine can do to make a mess of things. I don't think that changes much if it's "just" the hypervisor that's malicious instead of the hypervisor and kernel. The solutions end up looking the same - you want to minimise your attack surface, you need to think carefully about clocks and time sequencing, side channel attacks, etc.

I_am_tiberius 6y ago

I guess a database as a service instance at Google will still be accessible for Google in a decrypted way?

nellydpa 6y ago
Unless you run a database in the Confidential VM, can run mySQL, postgresql, MariaDB. Google managed db service, say GCP CloudSQL is not supported...

kop316 6y ago

Does anyone know what mode of AES that SEV (or SME) uses? I have been reading though all of AMD's documents, and I cannot find what mode of AES that SEV (or SME) uses. I find it extremely odd that this is not called out in any of AMD's documents, and frankly a bit worrisome. For the record, "A Comparison Study of Intel SGX and AMD Memory Encryption" [1] claims a modified version of AES-ECB is what SEV uses, BUT their reference links to AMD's whitepaper [2], which does NOT say anything about their mode, so I do not consider [1] to be a trustworty resouce. [1] https://caslab.csl.yale.edu/workshops/hasp2018/HASP18_a9-mofrad_slides.pdf https://caslab.csl.yale.edu/workshops/hasp2018/HASP18_a9-mof... [2] https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf https://developer.amd.com/wordpress/media/2013/12/AMD_Memory...

nellydpa 6y ago
The answer to your question: The AES mode AMD SEV uses is similar to XEX. AMD computes a tweak value based on the physical memory address and performs an xor-encrypt-xor operation. The tweak algorithm used on Rome (2nd gen EPYC) is based on GF math and uses a random value that is changed on each boot.
tux3 6y ago
They document a "physical address based tweak". My understanding is that this is xoring a function of the physical address with each 128bit block before going into AES-ECB (and that function is that same for every VM on your system).
- kop316 6y ago
  I only saw that in "A Comparison Study of Intel SGX and AMD Memory Encryption", which per my grandparent comment, is not a trustworthy source (they reference the whitepaper, and the whitepaper doesn't say anything about it). Is that documented in an actual AMD source, or even talk?
  - tux3 6y ago
    As far as I know, the whitepaper is all you will find publicly. It does mention the tweak (on page 4), only if you want the details and don't trust the third-party papers, you will have to reverse-engineer that yourself =]

blickentwapft 6y ago

I kind of assumed all my cloud computing resources were already private and confidential. Not so?

jagged-chisel 6y ago
Do you mean those resources physically located with you? That's a good assumption. Or do you mean those resources physically located in someone else's data center running on their hardware and software platforms among their infrastructure and only assigned to your task as-needed? That's a bad assumption.
- deleted 6y ago
  [deleted]
kanobo 6y ago
Data in cloud and probably on the device you're using right now is mainly only encrypted while sitting on the disk and when bouncing around the net. The difference here is that the data is also encrypted throughout its life - while in memory and while the data is getting processed on the machine.
nellydpa 6y ago
You are right, data is private and confidential when it is ingested to the cloud and/or stored in the cloud, not when processed. Encryption of "data-in-use" is the 3rd leg in data protection of sensitive data, and it became possible with hw capabilities in new CPU chipsets, from AMD and Intel, as it has to be hardware based (better security and performance).
- thu2111 6y ago
  As storage and ingestion requires processing, that's the same as saying it's not private at any point when in the cloud. And that's not necessarily a big deal. If you trust Google or AWS to hold all your business and customer data, no problem (and if your customers transitively have that trust). But I think there's a lot of denial about this fact: the cloud has all your data and all your customers data. Fixing that is really, really hard. It's not anywhere near as simple as Google are claiming in this announcement, certainly not "tick a box and it's switched on".

nemothekid 6y ago

Is this homomorphic encryption or something else?

nellydpa 6y ago
Homomorphic encryption enables computation to be performed on encrypted data without the need to decrypt it on the CPU. Compared to Confidential Computing approaches, the processing complexity of FHE is quite high, especially for tasks that require execution of complicated algorithms, making it hard to scale with this approach. Confidential VMs with AMD SEV decrypt data within VMs and keep it encrypted "in-use" by encrypting memory with a key generated by AMD secure processor (non-extractable) per VM. After processing data and code can be encrypted back to keep it protected at-rest.
- MereInterest 6y ago
  I don't understand, and couldn't get any information from the article either. If the data are decrypted within the VM, then it is still decrypted at that point, and the host machine can read it.
  - theevilsharpie 6y ago
    The data is transparently encrypted and decrypted specifically within the processor. The OS kernel on the host machine doesn't have access to the unencrypted contents of the guest VM's memory. > I don't understand, and couldn't get any information from the article either. See this wiki article for more info on this class of technology: https://en.wikipedia.org/wiki/Data_in_use https://en.wikipedia.org/wiki/Data_in_use
  - nellydpa 6y ago
    You can access memory within a VM, not outside of a VM. Host machine with a hypervisor is not within a VM instance, so it will not be able to read your VM memory. The memory is encrypted all the time, but when the instruction has to be executed on CPU, memory controllers (only and only have access to the keys of this VM) decrypt the instruction to execute it on cpu in clear. For FHE, cpu instructions are executed on AES encrypted blocks, and will take significant time, so not very practical today. Does it make sense?

Dyaz17 6y ago

What is the attack Vector that this solution prevent ? Am I missing something obvious ? Will it prevent Google from being able to have a Root access to the VM? From my understanding it does not seem to protect from Google. If they are still able to have a Root Access to the VM it does not matter if the memory is encrypted or not. The only thing that I see, is in case of a spectre/meltdown vulnerabilty where the isolation of the RAM fails...

nellydpa 6y ago
GCP does not have root access to the customers VMs. Confidential VMs with AMD SEV create an additional cryptographic isolation layer (in addition to virtualization one) between tenants and Google infra, mitigate 0days guest escapes, make observability attacks less possible, protect against some set of DMA attacks, and mitigate memory physical access attacks. To add to this not all spectre variants are applicable to AMD SEV, e.g. L1TF or foreshadow is not.
- derefr 6y ago
  > GCP does not have root access to the customers VMs I mean, they have physical access to the hypervisor host machines, where they could do anything they like to them, e.g. tap the JTAG pins of the CPU. Insofar as you assume that the attack here is “the NSA compels Google to gather evidence against you”, the lack of just being able to log into the VM doesn’t really change much.
  - asah 6y ago
    This protects against remote rogue employees and intruders. As for physical attacks, Google is ultra paranoid about physical access to DCs, and I think we can quickly agree that rogue employees and outsiders would have little chance of successful attack given the outrageous (and secret) methods that Google employs. Remember, this is one of the most-attacked organizations in the world, they've had decades (plural) to enact defenses and test them, and a successful attack would cost them over $10 billion - there's a virtually unlimited budget for physical defense. Circa 2020, I'd put Google's physical intrusion defenses up against most military installations.

hlandau 6y ago

May as well note: SEV relies on AMD-signed vendor firmware blobs. This means that AMD, or anyone who can get their keys, can compromise the security of SEV.

nellydpa 6y ago
Actually, the integrity of the AMD microcode can be verified using Google stackdriver as part of VM audit logs, together with the integrity of the VM kernel.

gchokov 6y ago

This is a terrible name. Assume everything else is not confidential!

nellydpa 6y ago
But everything else is not actually confidential... Confidentiality means limited visibility, when you process your data, the memory is in clear without this tech, or Intel SGX that offer confidentiality and integrity.

eloff 6y ago

So what does SEV actually protect against? Something like heartbleed would still happily decrypt and transmit confidential data. Something like speculative side channel attacks would still speculate on the unencrypted memory right? Rowhammer would still flip bits, but now one bit flipping would turn an entire 128 bit block into garbage when decrypted? It seems like that would at least make rowhammer a lot harder to exploit into a privilege escalation. ECC memory already gave some limited protection here.

theevilsharpie 6y ago
> Something like speculative side channel attacks would still speculate on the unencrypted memory right? This wouldn't prevent a Spectre attack or similar cache-based attack, as the memory would be decrypted at that point. However, it would mitigate attacks like Meltdown or Rowhammer.
- eloff 6y ago
  I don't see how it protects against meltdown, wouldn't the memory still get decrypted by the escalated access? Edit: If each VM has it's own key, then they couldn't read each other's memory with meltdown. I think that must be the angle.
  - theevilsharpie 6y ago
    > I don't see how it protects against meltdown, wouldn't the memory still get decrypted by the escalated access? No. A particular VM's memory is decrypted by that VM's key. Assuming that AMD's CPUs were vulnerable to a hypothetical attack similar to Meltdown, either a VM or a guest would be able to dump the machine's memory, but the memory contents belonging to other VMs would be encrypted and unintelligible.
    - eloff 6y ago
      I think my edit and your comment passed each other on the wire. That makes sense, it gives hardware protection from privilege escalation between VMs on the same host. Be it through a hardware exploit or hypervisor vulnerability.

Illniyar 6y ago

Is there demand for such a thing? I mean what is the use case where one would want this level of security.

nellydpa 6y ago
Quite a few: protect sensitive data in the cloud from the tenants and cloud providers, protect my clients sensitive data, address some requirements of the regulated markets, mitigate some privacy regulations, and a few new: collaborative computing with untrusted parties?

dsr_ 6y ago

Technology, technology, blah blah blah. Tell me this: will Google indemnify you against all your losses proportional to the amount they are to blame? i.e. if you lose $50 million because you relied on Google's "confidential VM" and an investigation shows it's 100% because Google didn't protect the VM, do you get a year's worth of fees back or $50MM?

occamrazor 6y ago
The SLA normally covers only the cost of running the VM, or a small multiple thereof. You can negotiate a better SLA, but you’re unlikely to get it. A better alternative is insurance. There are many insurers that offer contingent business interruption coverage for failure of cloud infrastructure, among other causes.
panarky 6y ago
Will the bank indemnify you against all your losses if a thief breaks into your safe deposit box?
sl1ck731 6y ago
I've been thinking about this in regard to AWS. The encryption at rest for most things is completely transparent so the only thing your really protected against is someone walking into a data center and grabbing your drive somehow. Or improperly disposed drives. Maybe some kind of hypervisor or SAN exploit but I don't know much about that. AWS seems to have turned part of the cloud operating model they are supposed to be responsible for back onto the user and no one questions it.
- WrtCdEvrydy 6y ago
  Sorry, here's your cloud fees back.
  - ape4 6y ago
    Self hosting (remember that) seems best for really confidential things.

josephcsible 6y ago

I don't like this technology. If it works as claimed, it could be used for almost unbreakable DRM.

theevilsharpie 6y ago
It already has been in a sense, as the underlying technology for SEV was developed by AMD to protect the DRM running on game consoles. That being said, AMD SEV is transparent to the underlying applications and users, so anyone with an interest in protecting memory from certain classes of attacks (e.g., Meltdown, Rowhammer) can benefit. Other technology in this space (e.g., Intel SGX, Arm TrustZone) requires the application to explicitly support the secure enclave, so their usefulness to a typical end-user is much more limited, and as such, they aren't really used much other than to enable DRM.

deleted 6y ago

[deleted]

2dvisio 6y ago

This seems a move to make people handling sensitive data (E.g. healthcare and insurance) make sure they have peace of mind and can tick the box “security and privacy” off? Even neutralising the potential issue of being linked with the omniscient google? How will MS and AWS respond will be interesting.

theevilsharpie 6y ago
Confidential VM is essentially productizing AMD SEV technology. Intel will have something similar on the market in the (hopefully near) future. Given that AWS and Azure also use AMD and Intel equipment, I'd expect them to introduce similar functionality. (AWS is probably closer as SEV support is built into Linux, whereas Windows has no support for it as far as I can tell.)

als0 6y ago

It's interesting that there's no mention of Intel SGX in this blog post.

theevilsharpie 6y ago
It doesn't use Intel SGX, nor would SGX work with such a service. Intel is working on a competing technology -- Total Memory Encryption -- but AMD beat them to market by quite a bit.

mtgx 6y ago

Couldn't Signal use this, too? I know they use the more limited SGX now.

yasoob 6y ago

They state in the press release: > With the beta launch of Confidential VMs, we’re the first major cloud provider to offer this level of security and isolation while giving customers a simple, easy-to-use option for newly built as well as “lift and shift” applications. How is Google's offering different from the Confidential Compute Microsoft already offers?[1] [1] https://azure.microsoft.com/en-us/solutions/confidential-compute/ https://azure.microsoft.com/en-us/solutions/confidential-com...

saagarjha 6y ago
This uses AMD's SVE, which as I understand is more akin to Intel's MPX than SGX (which is what Microsoft is using).
- deleted 6y ago
  [deleted]
- theevilsharpie 6y ago
  The equivalent Intel technology is TME, which is not present in any commercially-available processor yet. MPX was an instruction extension that was never widely adopted and that Intel has deprecated.
strstr 6y ago
SGX has a stronger security model, but targets enclaves instead of VMs. If you want something to run in SGX, you will likely need to rewrite the software (you can’t call syscalls directly in SGX since you cannot trust their results anyway). SEV’s security model is weaker (no integrity), but lets you use essentially normal VM images. Disclaimer: I work at Google in this space.
Uptrenda 6y ago
The Microsoft solution uses Intel SGX and all it gives you is access to a machine that has an SGX-enabled processor with some SDK tools pre-installed to use it. The SDK is C-based and reimplements parts of the C standard library -- having non-standard arguments and return types in some cases (like say unsigned instead of signed.) In this case: you have to write all the code yourself and manage the secure processor features to use it. It's application-level, same host / OS. Googles offering is more intuitive. Google Cloud already stores data on VMs encrypted to disk and handles decryption to be able to start the VM. But once the data is in memory its unencrypted and could be read by other processes. On a bare metal machine there may be more than one VM using portions of the same processor with physical access to the same memory range. So compromising this at a higher level would effect other customers. With the new offering it supports encrypted memory isolation for a virtualised VM. It's on a VM-level or 'whole operating system' meaning there is no need to write any special code to take advantage. You just tick a box. Tech is by AMD and not Intel. Both of these options support different use-cases, IMO. Microsofts confidential compute allows you to manage untrusted applications on the same host with a high level of control. You can prove to other machines running the same app that you're doing this 'securely.' The Google solution doesn't give you the same level of granularity but is much, much easier to use for those who just want to take advantage of better memory protection and integrity checks. My thoughts on this are mixed though because: 1. While the products are clearly very different -- Intel's SGX tech has already had numerous security vulnerabilities and that doesn't make me very optimistic AMD will have magically solved those issues. 2. The general advice in finance for highly sensitive data is not to use VMs, period. Since privilege escalation on one VM could potentially lead to access to the bare metal and hence access to the other VMs. Some of these risks still seem relevant even if memory protection is being used. I.E. it's better not to use VMs if you care about security. Trying to attract more highly sensitive data to 'the cloud' makes me nervous, to be honest. 3. I like the concept in general. Even though it's not a silver bullet it's nice to be able to have access to this option.

algorithm314 6y ago

It is funny that Kubernetes,Istio, Asylo etc are transliteration of greek words and Google has trademarks on them.

cperciva 6y ago

Confidential Computing environments keep data encrypted in memory and elsewhere outside the central processing unit (CPU). Aren't Amazon's Graviton 2 processors specified to do this too?

theevilsharpie 6y ago
My knowledge of Graviton is limited, but based on Amazon's description of Graviton 2's encryption capabilities, it seems more like an equivalent to AMD's Secure Memory Encryption (SME), rather than SEV.
- ENOTTY 6y ago
  It's a lot more than just a SME equivalent. They've designed the management plane in a really clever way that makes it more similar to SGX/SEV than at first glance. I recommend watching this video https://www.youtube.com/watch?v=kN9XcFp5vUM https://www.youtube.com/watch?v=kN9XcFp5vUM