
Confidential VMs - caution
https://cloud.google.com/blog/products/identity-security/introducing-google-cloud-confidential-computing-with-confidential-vms
======
kop316
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-mof...](https://caslab.csl.yale.edu/workshops/hasp2018/HASP18_a9-mofrad_slides.pdf)

[2]
[https://developer.amd.com/wordpress/media/2013/12/AMD_Memory...](https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf)

~~~
tux3
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
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
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 =]

~~~
kop316
Fair enough. That's what I assumed, but the HN crowd is pretty resourceful
too.

------
Dyaz17
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
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
> 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.

~~~
remus
> 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.

For most people (and especially businesses) this is a totally unrealistic
security aim. If what you're worried about is the government using it's legal
ability to compel people and businesses to provide evidence then there's ~no
product or service from that country that you could realistically use.

~~~
derefr
I mean, yes, there's no service where the security/privacy is _contractual_ ,
that is safe from the state overriding the contract.

But the promise of things like homeomorphic encryption, is that you can do a
computation on a truly _untrusted substrate_ , i.e. you can trust computations
performed by an untrusted adversary, and also know that they didn't learn
anything about those computations. It's a _technical_ solution to
security/privacy, not a contractual one.

The ideal that everyone's hoping for, is that there's a way to get that same
kind of _technical_ guarantee from cloud compute providers, without needing a
layer of maths that makes Monte Carlo quantum simulation look fast.

~~~
Spooky23
All commercial activities are at the core protected by contractural
protections and good faith. Cloud is not as different as you may think.

Any other expectation of protection from the state are a limited based on
probability, seriousness of the matter, and your potential culpability. Your
employees, service providers and others can be required to provide information
without informing you. In extreme cases, agents will pose as utility, security
or building management.

~~~
derefr
> Your employees, service providers and others can be required to provide
> information without informing you. In extreme cases, agents will pose as
> utility, security or building management.

...and homeomorphic encryption would stop all of those attacks. Presuming it's
a homeomorphically-encrypted substrate for an autonomous agent, making its own
"evaluations" of the data it can perceive from the outside world (ala a smart
contract with access to an oracle) rather than simply trusting data from the
insecure domain that happens to be signed with the right key.

This is also, y'know, the security architecture that allows nuclear submarines
to avoid being subverted by an enemy nation that has temporarily gained
control of the White House. The sub's commander needs to know not only that
they've received the order, but also that the world really _looks like_ one
where such an order would be legitimately given. The isolated secure agent,
speaking to an insecure principal, needs not only proof of their credentials,
but also needs to _independently_ verify their _claims_ about the state of the
world. (And, if they can do that, the system is often architected such that
the principal won't even communicate in the moment, but instead has just left
flowchart-like orders in advance, involving various dead-man's-switch timers
and so forth.)

~~~
Spooky23
> ...and homeomorphic encryption would stop all of those attacks.

It may, but how many business processes are as well thought out as nuclear
missile submarines?

------
dsr_
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?

~~~
simonebrunozzi
You raise a very, very important (and debated) point.

(disclosure: I was at AWS 2008-2014, and VMware's cloud business 2014-2016;
opinions my own, no disclosure of secrets, etc etc)

Most SLAs only indemnify you for the paltry infrastructure costs in relation
to the downtime or accident.

Few SLAs are more extensive, covering for example data loss.

AFAIK, no SLA exists that extensively cover such type of loss. (perhaps with
the exception of heavily customized contracts, sometimes part of a military
contractor deal, where numbers are out of this world and there's huge margins
for clauses and exceptions everywhere).

They don't exist for two reasons, IMHO:

1) it's very complicated to define metrics related to the amount to be
indemnified, and

2) it's hard to keep that amount current, based on how the data changes, or
the architecture changes.

It would be interesting to see an "insurance" for these kind of things. I once
thought of such a product, just after I left AWS, and for a little while I
entertained the idea of launching a startup to go after that market.

~~~
chrismorgan
I have long felt that almost all SLAs are completely toothless and thus
_certainly_ not worth paying extra for.

A few comments on this topic from 44 days ago:
[https://news.ycombinator.com/item?id=23362073](https://news.ycombinator.com/item?id=23362073)

Now insurance, that sounds like a much more promising facet for protection.
But still I wonder about the incentives: SLAs are offered by the original
company and mean that they have skin in the game. (Well, they _already_ have
skin in the game as you’re a customer and if they mess things up you will look
less favourably upon them as a provider, but the SLAs should in theory provide
more direct financial incentive to avoid breaking things.) Insurance would be
offered by by a disinterested third party¹, and thus lose that SLA incentive.

¹ Insurance in general relies upon this for scale and safety; I can’t imagine
trusting any provider offering first-party insurance: they’d likely go
bankrupt the first time anything went wrong.

~~~
saagarjha
The SLA you mentioned there was problematic because it didn't actually cover
how much you were losing if the service went down. A SLA that _would_ cover
that would certainly not be useless, and likely not be toothless either, even
if insurance was involved.

~~~
chrismorgan
I wasn’t speaking about any one SLA; I was speaking about the contents of
pretty much _every_ SLA I’ve ever looked at. Seriously. Coincidentally, that
very day, I happened to find what is I think the best SLA I’ve found, which
went as far as refunding 5× what you paid them for the month after a certain
amount of downtime, and _almost_ added it to that comment as the first decent
one I’d come across, but as I read further, the amount of downtime it took to
get to any meaningful refund still seemed unreasonably long, so I ended up
deciding it was still mostly toothless, though perhaps its gums were just a
mite tougher than most.

 _Negotiated_ SLAs may be able to take into account customer business losses
(I don’t know, I’ve never seen a negotiated one), but standard SLAs _never_
include that.

------
hlandau
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
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.

------
yasoob
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-
com...](https://azure.microsoft.com/en-us/solutions/confidential-compute/)

~~~
saagarjha
This uses AMD's SVE, which as I understand is more akin to Intel's MPX than
SGX (which is what Microsoft is using).

~~~
theevilsharpie
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.

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

~~~
dijit
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.

~~~
acdha
> 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
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.

~~~
acdha
Right: my point is simply that you have to start with a threat model and make
reasoned decisions based on that and your budget. “always argue” is the same
as “wrong for a significant number of people” even if it's right for your
particular circumstances.

~~~
dijit
"Always argue against" does not equal "never give in".

But I can see how you read it that way.

I would definitely challenge you on 'wrong for a significant number of people'
because if you're focusing on security then it's likely a core principle; and
therefore you need to understand and be able to effectively argue your case.

And that doesn't matter if you agree with my position or not for that last
point to be true.

------
mfer
> 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.

------
eloff
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
> 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
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
> 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
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.

------
2dvisio
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
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.)

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

~~~
nellydpa
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.

------
zimmerfrei
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-
strengthen...](https://www.amd.com/system/files/TechDocs/SEV-SNP-
strengthening-vm-isolation-with-integrity-protection-and-more.pdf)

~~~
zimmerfrei
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/)

------
rwmj
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.

~~~
theevilsharpie
> 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
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.

~~~
theevilsharpie
> Intel actually had a similar tech without the RAM encryption some time ago,
> called TXT.

Given that RAM encryption is literally the core function of SEV, any
functionality that lacks it is by definition dissimilar.

~~~
thu2111
TXT had RAM protection, as in, other software or hardware devices couldn't
read the protected memory areas. RAM encryption itself is primarily about
stopping bus sniffing or cold boot attacks. Useful, but by no means the only
kind of protection you need. Especially because combining encryption with
authentication is very hard. It is easy to forget that encryption doesn't stop
someone flipping bits and you can corrupt the plaintext in ways useful to an
attacker by doing so, hence the rise of AES/GCM. But I don't think SEV uses
AEAD?

But the core technology is basically the same concept. You get a protected
memory space (to some degree of protection), you can derive keys linked to the
loaded code hash, and you can do remote attestation to set up a Diffie-Hellman
handshake with the remote protected domain. All that stuff is identical
between TXT and SEV.

------
blickentwapft
I kind of assumed all my cloud computing resources were already private and
confidential.

Not so?

~~~
nellydpa
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
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".

------
cperciva
_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
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
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)

------
nemothekid
Is this homomorphic encryption or something else?

~~~
nellydpa
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
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
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)

------
maayank
How is SEV compared to SGX?

~~~
nix23
SEV is atm considered 'secure' SGX is not:

[https://arstechnica.com/information-
technology/2020/03/hacke...](https://arstechnica.com/information-
technology/2020/03/hackers-can-steal-secret-data-stored-in-intels-sgx-secure-
enclave/)

~~~
als0
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...](https://www.theregister.com/2019/06/26/amd_epyc_key_security_flaw/)

~~~
benlivengood
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

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

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

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

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

~~~
theevilsharpie
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.

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

~~~
nellydpa
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?

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

~~~
theevilsharpie
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.

