5 ms·

SEV (Secure Encrypted Virtualization, [1]) is a hugely interesting feature that will be available with Zen. Once it's mature and perfected, it would allow you t

by geertj 10y ago

SEV (Secure Encrypted Virtualization, [1]) is a hugely interesting feature that will be available with Zen. Once it's mature and perfected, it would allow you to securely run a VM in the cloud that is protected against someone who controls the hypervisor. And you'd also be able to attest that indeed you're running in such a protected VM. How do you protect against someone controlling the hypervisor? Read the paper. But the high level is to encrypt memory using keys that cannot leave the processor and are only available to a specific VM ASID (Address Space Identifier), assisted by a secure firmware similar to the Secure Enclave. Attestation uses an on-chip certificate signed by an AMD master key during fabrication. There were some discussions on this on the linux-kernel mailing list [2]. As I understand it, the current generation of SEV is still somewhat leaky, but there's no fundamental reason why those leaks cannot be closed. [1] http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/... [2] http://www.mail-archive.com/linux-doc@vger.kernel.org/msg02578.html http://www.mail-archive.com/linux-doc@vger.kernel.org/msg025...

tcoppi 10y ago
This is interesting. The most compelling use case IMO is protection against cold boot attacks rather than virtualization, at least until SEV has been proven empirically to do what they claim. Virtualization security is hard to get right in general and adding another layer of complexity probably won't help in the short term.
- emn13 10y ago
  Even if it turns out to be leaky, it could still be a big deal: I think it's fair to say that the greatest cloud risk isn't actively and persistently hostile providers - mostly because that sounds like an almost hopeless task. A more realistic risk is that via a VM-breakout or other hack hostile code manages to run on the hypervisor or to at least indirectly influence the hypervisor and other VMs. And that kind of code may well be harder to exploit with even slightly leaky encryption. A hacked hypervisor may not be entirely under the control of the hacker; or breaking the encryption may cause side-effects (such as instability) that causes watchers to take note; or it may simply be quite complex and require case-by-case exploits that are generally impractical. Even a less that perfect protection from the hyper-visor may still have some value. I'd be more worried about the performance overhead, personally - I can't imagine using this if the impact is significant, and it seems like it almost has to be.
  - usefulcat 10y ago
    > I'd be more worried about the performance overhead, personally - I can't imagine using this if the impact is significant, and it seems like it almost has to be. Not necessarily. Bandwidth to main memory is already typically several times less than to L1 or L2 caches. If processor caches are not encrypted, then it seems conceivable that you could have some dedicated encryption/decryption silicon and it probably wouldn't even have to be as fast as it would need to be for general purpose use (like the Intel AES instructions). Even if it does cost bandwidth or latency to main memory, if it's by a small enough amount it could still be a worthwhile tradeoff for some applications.
  - sliverstorm 10y ago
    I think it's fair to say that the greatest cloud risk isn't actively and persistently hostile providers - mostly because that sounds like an almost hopeless task. Definitely agree. I know we like our security systems impervious to anyone and everyone, be they script kiddie or the entire NSA. However if you hand your machine over to someone else to run, (in either VM guest or box form), I think you need to acknowledge that you are incontrovertibly accepting slight vulnerability to the colo/VM host.
urza 10y ago
It reminds me of Permutation City, the scifi book by Greg Egan.. encrypted realities inside other realities.. :)
- nitrogen 10y ago
  See also Rainbows End by Vernor Vinge, where a secure encrypted sub-CPU plays a role.
spaceheeder 10y ago
In addition to cloud VMs, I wonder what applications this might have on local systems. Systems that boot from encrypted partitions and can't have the keys recovered by cold boot attacks? Secure graphics acceleration of different guests in a Qubes system? etc.
- geertj 10y ago
  I believe that the enabling technology for SEV (SME - Secure Memory Encryption) would indeed protect against cold boot attacks. The SME keys are not stored in memory themselves and therefore once the CPU reboots and the SME keys are erased, the memory contents are lost forever.
- fulafel 10y ago
  DRM and keeping the user from rooting their PC. This is like MS/Intel Trusted Computing on steroids.
  - snuxoll 10y ago
    AMD has had a on-die management CPU (dubbed the PSP - Platform Security Processor) for years now, similar to the Intel ME, this is something completely different. Memory encryption doesn't prevent you from doing anything with your device, as far as userland is aware they still have access to the full address space with no knowledge encryption is happening - the only difference is memory IS encrypted so even if you manage to freeze memory to preserve the charge it will be useless as soon as it is removed from the host machine or it is rebooted.
    - kuschku 10y ago
      The whole point is that you, as user, can not use your (legally guaranteed right in the EU) to debug software, reverse it, modify it, etc. That is a big fucking disadvantage. If I buy software (buying a license also counts, if you’re in the EU, or renting a license), I want to be able to use it like I’d use a table I buy: I can saw one leg off, repaint it, turn it into a chair. I want to be able to mod the game, skin it, theme it, do a total conversion. This is preventing me from using my rights.
mtgx 10y ago
Is SME like Intel's SGX?
- anonymousDan 10y ago
  Yup. I'm not too up to date on the specifics, but one advantage I remember reading from the paper over SGX is that you can run programs with raised privileges, whereas in SGX enclaves can only have user privileges.
api 10y ago
> "it would allow you to securely run a VM in the cloud that is protected against someone who controls the hypervisor" > Attestation uses an on-chip certificate signed by an AMD master key during fabrication. This is absolutely fantastic for security in the cloud, but it is important to note that this will not protect against nation state level actors. Rest assured that the USG will obtain the AMD master signing key with or without AMD's permission. Other nation states may do likewise. The rest will have to wait for a leak, and if that key is leaked this feature will become almost nonexistent.
AnthonyMouse 10y ago
I still don't understand how this is ever supposed to work. Generally when someone finds a vulnerability, you take countermeasures or take the system offline until it can be patched (or apply the patch immediately). With this, the party in control of the system is also in control of that, so every time a new vulnerability is found they can exploit it before patching it to retroactively get access to your data. Or never patch it at all and use the vulnerability itself to forge attestations that the vulnerability is patched.
- sliverstorm 10y ago
  It might not make your guest truly impervious, but it certainly raises the bar for your bad actor host. Depending on how determined you imagine your bad actor host, you can probably never get around things like "zero day is discovered, host disconnects guest from internet preventing you from patching zero day, exploits guest". Or are you talking about vulnerabilities in SEV itself?
  - AnthonyMouse 10y ago
    Vulnerabilities in SEV itself. In theory you can't actually do it at all. The key is inside the chip, the attacker has physical control over the chip, an attacker with enough resources is going to be able to extract the key. You have no hope against a state-level attacker or even many university research departments. The assumption seems to be that the attacker won't be that sophisticated. The problem is there are also likely to be attacks which won't require significant resources once published. Researchers are always coming up with new ways to extract keys from "tamper proof hardware" using timing or power consumption or whatever else. Some future version of the hardware will protect against that specific attack but that's too late for all the secrets you trusted to the current version.
lancemjoseph 10y ago
I thought homomorphic encryption was supposed to fill the niche of allowing one to securely run VMs in a cloud environment. I've not heard of serious progress on this front the last time I went looking. Will we always require hardware with a "secure enclave"-like device to safely store keys in a public cloud? Is it possible to implement this scheme purely in software or is some "trusted" hardware always necessary?
- Dylan16807 10y ago
  Homomorphic encryption is currently hilariously slow as I understand it, and even if you solve that it can't branch on data. All paths have to be evaluated and summed.
- MertsA 10y ago
  Forewarning, I am by no means an expert on anything that follows. Homomorphic encryption would allow for "true security" where the party doing the computation doesn't ever have the encryption keys necessary to see what data they're operating on. This is something more akin to a TPM. The key that can read all of the data is in the possession of the party doing the computation, but it's stored in the CPU and the CPU will not give that key to anyone. Theoretically the key could be read off of the CPU but in practice this would require either a flaw, sidechannel, or a lot of time with an electron microscope. For practical purposes, I believe that all implementations of secure cloud computing are going to be like this where the key is just secured physically. It's possible with homomorphic encryption to have someone securely do computations on data that they can't see all in software, but I just don't see any major breakthroughs happening that would make this fast enough to be practical.
derefr 10y ago
Sounds like something that would make the claims made by https://en.wikipedia.org/wiki/Denuvo https://en.wikipedia.org/wiki/Denuvo copy-protection, actually plausible.
anonymousDan 10y ago
Do you know is there hardware available with SEV capabilities yet? Or is there even a roadmap/timeline for its release somewhere? Would be really interested to get my hands on it.

by geertj 10y ago

tcoppi 10y ago

This is interesting. The most compelling use case IMO is protection against cold boot attacks rather than virtualization, at least until SEV has been proven empirically to do what they claim. Virtualization security is hard to get right in general and adding another layer of complexity probably won't help in the short term.

emn13 10y ago
Even if it turns out to be leaky, it could still be a big deal: I think it's fair to say that the greatest cloud risk isn't actively and persistently hostile providers - mostly because that sounds like an almost hopeless task. A more realistic risk is that via a VM-breakout or other hack hostile code manages to run on the hypervisor or to at least indirectly influence the hypervisor and other VMs. And that kind of code may well be harder to exploit with even slightly leaky encryption. A hacked hypervisor may not be entirely under the control of the hacker; or breaking the encryption may cause side-effects (such as instability) that causes watchers to take note; or it may simply be quite complex and require case-by-case exploits that are generally impractical. Even a less that perfect protection from the hyper-visor may still have some value. I'd be more worried about the performance overhead, personally - I can't imagine using this if the impact is significant, and it seems like it almost has to be.
- usefulcat 10y ago
  > I'd be more worried about the performance overhead, personally - I can't imagine using this if the impact is significant, and it seems like it almost has to be. Not necessarily. Bandwidth to main memory is already typically several times less than to L1 or L2 caches. If processor caches are not encrypted, then it seems conceivable that you could have some dedicated encryption/decryption silicon and it probably wouldn't even have to be as fast as it would need to be for general purpose use (like the Intel AES instructions). Even if it does cost bandwidth or latency to main memory, if it's by a small enough amount it could still be a worthwhile tradeoff for some applications.
- sliverstorm 10y ago
  I think it's fair to say that the greatest cloud risk isn't actively and persistently hostile providers - mostly because that sounds like an almost hopeless task. Definitely agree. I know we like our security systems impervious to anyone and everyone, be they script kiddie or the entire NSA. However if you hand your machine over to someone else to run, (in either VM guest or box form), I think you need to acknowledge that you are incontrovertibly accepting slight vulnerability to the colo/VM host.

urza 10y ago

It reminds me of Permutation City, the scifi book by Greg Egan.. encrypted realities inside other realities.. :)

nitrogen 10y ago
See also Rainbows End by Vernor Vinge, where a secure encrypted sub-CPU plays a role.

spaceheeder 10y ago

In addition to cloud VMs, I wonder what applications this might have on local systems. Systems that boot from encrypted partitions and can't have the keys recovered by cold boot attacks? Secure graphics acceleration of different guests in a Qubes system? etc.

geertj 10y ago
I believe that the enabling technology for SEV (SME - Secure Memory Encryption) would indeed protect against cold boot attacks. The SME keys are not stored in memory themselves and therefore once the CPU reboots and the SME keys are erased, the memory contents are lost forever.
fulafel 10y ago
DRM and keeping the user from rooting their PC. This is like MS/Intel Trusted Computing on steroids.
- snuxoll 10y ago
  AMD has had a on-die management CPU (dubbed the PSP - Platform Security Processor) for years now, similar to the Intel ME, this is something completely different. Memory encryption doesn't prevent you from doing anything with your device, as far as userland is aware they still have access to the full address space with no knowledge encryption is happening - the only difference is memory IS encrypted so even if you manage to freeze memory to preserve the charge it will be useless as soon as it is removed from the host machine or it is rebooted.
  - kuschku 10y ago
    The whole point is that you, as user, can not use your (legally guaranteed right in the EU) to debug software, reverse it, modify it, etc. That is a big fucking disadvantage. If I buy software (buying a license also counts, if you’re in the EU, or renting a license), I want to be able to use it like I’d use a table I buy: I can saw one leg off, repaint it, turn it into a chair. I want to be able to mod the game, skin it, theme it, do a total conversion. This is preventing me from using my rights.

mtgx 10y ago

Is SME like Intel's SGX?

anonymousDan 10y ago
Yup. I'm not too up to date on the specifics, but one advantage I remember reading from the paper over SGX is that you can run programs with raised privileges, whereas in SGX enclaves can only have user privileges.

api 10y ago

> "it would allow you to securely run a VM in the cloud that is protected against someone who controls the hypervisor" > Attestation uses an on-chip certificate signed by an AMD master key during fabrication. This is absolutely fantastic for security in the cloud, but it is important to note that this will not protect against nation state level actors. Rest assured that the USG will obtain the AMD master signing key with or without AMD's permission. Other nation states may do likewise. The rest will have to wait for a leak, and if that key is leaked this feature will become almost nonexistent.

AnthonyMouse 10y ago

I still don't understand how this is ever supposed to work. Generally when someone finds a vulnerability, you take countermeasures or take the system offline until it can be patched (or apply the patch immediately). With this, the party in control of the system is also in control of that, so every time a new vulnerability is found they can exploit it before patching it to retroactively get access to your data. Or never patch it at all and use the vulnerability itself to forge attestations that the vulnerability is patched.

sliverstorm 10y ago
It might not make your guest truly impervious, but it certainly raises the bar for your bad actor host. Depending on how determined you imagine your bad actor host, you can probably never get around things like "zero day is discovered, host disconnects guest from internet preventing you from patching zero day, exploits guest". Or are you talking about vulnerabilities in SEV itself?
- AnthonyMouse 10y ago
  Vulnerabilities in SEV itself. In theory you can't actually do it at all. The key is inside the chip, the attacker has physical control over the chip, an attacker with enough resources is going to be able to extract the key. You have no hope against a state-level attacker or even many university research departments. The assumption seems to be that the attacker won't be that sophisticated. The problem is there are also likely to be attacks which won't require significant resources once published. Researchers are always coming up with new ways to extract keys from "tamper proof hardware" using timing or power consumption or whatever else. Some future version of the hardware will protect against that specific attack but that's too late for all the secrets you trusted to the current version.

lancemjoseph 10y ago

I thought homomorphic encryption was supposed to fill the niche of allowing one to securely run VMs in a cloud environment. I've not heard of serious progress on this front the last time I went looking. Will we always require hardware with a "secure enclave"-like device to safely store keys in a public cloud? Is it possible to implement this scheme purely in software or is some "trusted" hardware always necessary?

Dylan16807 10y ago
Homomorphic encryption is currently hilariously slow as I understand it, and even if you solve that it can't branch on data. All paths have to be evaluated and summed.
MertsA 10y ago
Forewarning, I am by no means an expert on anything that follows. Homomorphic encryption would allow for "true security" where the party doing the computation doesn't ever have the encryption keys necessary to see what data they're operating on. This is something more akin to a TPM. The key that can read all of the data is in the possession of the party doing the computation, but it's stored in the CPU and the CPU will not give that key to anyone. Theoretically the key could be read off of the CPU but in practice this would require either a flaw, sidechannel, or a lot of time with an electron microscope. For practical purposes, I believe that all implementations of secure cloud computing are going to be like this where the key is just secured physically. It's possible with homomorphic encryption to have someone securely do computations on data that they can't see all in software, but I just don't see any major breakthroughs happening that would make this fast enough to be practical.

derefr 10y ago

Sounds like something that would make the claims made by https://en.wikipedia.org/wiki/Denuvo https://en.wikipedia.org/wiki/Denuvo copy-protection, actually plausible.

anonymousDan 10y ago

Do you know is there hardware available with SEV capabilities yet? Or is there even a roadmap/timeline for its release somewhere? Would be really interested to get my hands on it.