6 ms·

At this point SGX is just so broken that it seems like its only purpose is to provide PhD students something to write a paper on :) I'm hesitantly excited for

At this point SGX is just so broken that it seems like its only purpose is to provide PhD students something to write a paper on :) I'm hesitantly excited for AMD's SEV enclave to roll out. Anyone know if it's shaping up to be any better?

ENOTTY 6y ago
SEV has been subjected to its own share of attacks (and design/implementation fails), but note that it has a different threat model. * https://arxiv.org/pdf/1712.05090.pdf https://arxiv.org/pdf/1712.05090.pdf 2017 * https://arxiv.org/pdf/1612.01119.pdf https://arxiv.org/pdf/1612.01119.pdf 2017 * https://arxiv.org/pdf/1805.09604.pdf https://arxiv.org/pdf/1805.09604.pdf 2018 * https://ipads.se.sjtu.edu.cn/_media/publications/fidelius_hpca18.pdf https://ipads.se.sjtu.edu.cn/_media/publications/fidelius_hp... 2018 * https://seclists.org/fulldisclosure/2019/Jun/46 https://seclists.org/fulldisclosure/2019/Jun/46 2019 * https://www3.cs.stonybrook.edu/~mikepo/papers/severest.asiaccs19.pdf https://www3.cs.stonybrook.edu/~mikepo/papers/severest.asiac... 2019 * https://www.usenix.org/system/files/sec19-li-mengyuan_0.pdf https://www.usenix.org/system/files/sec19-li-mengyuan_0.pdf 2019 * https://arxiv.org/pdf/1908.11680.pdf https://arxiv.org/pdf/1908.11680.pdf 2019 * https://arxiv.org/pdf/2004.11071.pdf https://arxiv.org/pdf/2004.11071.pdf 2020 Any enclave technology will be reliant on the underlying security of the processor itself. Someone was going to have to go first. Intel happened to take greater risks in the name of performance, and all of their technologies (including their first-to-market enclave technology) are suffering reputational hits as a result. I'll also just mention that CrossTalk is the more interesting vulnerability affecting SGX that was disclosed today.
- usmannk 6y ago
  Oh huh, I see. Thanks for the papers. "Someone was going to have to go first. Intel happened to take greater risks in the name of performance, and all of their technologies (including their first-to-market enclave technology) are suffering reputational hits as a result." Very true, and a point worth making. Just curious, do you work closely with SGX/SEV? You were quick with the links!
anonymousDan 6y ago
SEV is fundamentally less secure than SGX because it only provides memory encryption but no integrity protection. Enclaves are a challenging problem given the much more aggressive threat model, but SGX is the better security model of the two IMO.
- lima 6y ago
  Yes - in a recent paper by Wilke et al[0], they nicely demonstrate how the lack of integrity checking can be exploited. SEV is a very new technology and its current (and previous) iterations have known weaknesses. The next generation of SEV will likely have SEV-SNP[1], which will prevent the host from writing guest memory/messing with the guest's page mappings. Will probably take a few more iterations to stabilize. At that point, it should provide decent security guarantees. Current-gen SGX has much stronger guarantees (conceptually, at least) with full memory integrity checking and less attack surface, but it suffers from CPU vulnerabilities, most of which AMD didn't have, and the integrity checks and architecture come at a large performance and development cost. SEV has different tradeoffs that make it much more useful for real-world use cases, while still providing strong security guarantees. [0]: https://arxiv.org/pdf/2004.11071.pdf https://arxiv.org/pdf/2004.11071.pdf [1]: 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...
  - anonymousDan 6y ago
    Oh nice, hadn't heard about SNP yet - looks interesting.
lima 6y ago
SEV is exciting because it has a much better cost-to-benefits ratio. It provides useful defense in depth without requiring any changes to the application stack - you can run regular VMs with syscalls, plenty of memory and high-bandwidth IO. SGX, on the other hand, is extremely limited and notoriously hard to target. It's even harder these days - you need specialized compilers and coding techniques to mitigate a number of attacks that can't be fixed by a microcode update. I reckon it's almost impossible to do serious SGX work these days without being under NDA with Intel such that you can work on mitigations during embargoes for the never-ending stream of vulnerabilities.
- deleted 6y ago
  [deleted]
- thu2111 6y ago
  SEV is exciting because it has a much better cost-to-benefits ratio. I think that's not actually true. The problem is if you believe SGX "needs" these sorts of defences/mitigations then so does SEV, because SEV VMs are not magically immune to side channel attacks and in fact suffer far more than just micro-architectural side channels because they also leak all disk and memory access patterns, network access patterns and so on. These sorts of side channels aren't the responsibility of any CPU to fix but are remarkably powerful. Sometimes it feels like SGX gets placed under a rather nasty double standard. Enclaves are "hard" because you "must" mitigate side channel attacks. SEV VMs are "easy" because nobody even tries at all. Indeed they cannot try - normal software isn't built to eliminate app level side channels. That's why enclaves are special programs to begin with. If you are happy to use existing non-hardened software though and just take the defence in depth argument, well, no problem - you can use SGX too. There are things like SCONE that let you run existing software inside enclaves. Unlike SEV, SGX is actually fixable when security bugs are found so it's meaningful to talk about using it. SEV has been theatre so far. It's not renewable, there's no equivalent of TCB recovery so nobody bothers trying to attack it because it's already been broken in unfixable ways before.
  - yths 6y ago
    You are right about the double standard but using enclaves means restructuring your application. Even SCONE requires porting. SEV gives you the warm and fuzzy feeling that you are doing something to improve security without having to do a lot of work, assuming that your favorite OS version has been ported to run in a "secure" VM.

ENOTTY 6y ago

SEV has been subjected to its own share of attacks (and design/implementation fails), but note that it has a different threat model. * https://arxiv.org/pdf/1712.05090.pdf https://arxiv.org/pdf/1712.05090.pdf 2017 * https://arxiv.org/pdf/1612.01119.pdf https://arxiv.org/pdf/1612.01119.pdf 2017 * https://arxiv.org/pdf/1805.09604.pdf https://arxiv.org/pdf/1805.09604.pdf 2018 * https://ipads.se.sjtu.edu.cn/_media/publications/fidelius_hpca18.pdf https://ipads.se.sjtu.edu.cn/_media/publications/fidelius_hp... 2018 * https://seclists.org/fulldisclosure/2019/Jun/46 https://seclists.org/fulldisclosure/2019/Jun/46 2019 * https://www3.cs.stonybrook.edu/~mikepo/papers/severest.asiaccs19.pdf https://www3.cs.stonybrook.edu/~mikepo/papers/severest.asiac... 2019 * https://www.usenix.org/system/files/sec19-li-mengyuan_0.pdf https://www.usenix.org/system/files/sec19-li-mengyuan_0.pdf 2019 * https://arxiv.org/pdf/1908.11680.pdf https://arxiv.org/pdf/1908.11680.pdf 2019 * https://arxiv.org/pdf/2004.11071.pdf https://arxiv.org/pdf/2004.11071.pdf 2020 Any enclave technology will be reliant on the underlying security of the processor itself. Someone was going to have to go first. Intel happened to take greater risks in the name of performance, and all of their technologies (including their first-to-market enclave technology) are suffering reputational hits as a result. I'll also just mention that CrossTalk is the more interesting vulnerability affecting SGX that was disclosed today.

usmannk 6y ago
Oh huh, I see. Thanks for the papers. "Someone was going to have to go first. Intel happened to take greater risks in the name of performance, and all of their technologies (including their first-to-market enclave technology) are suffering reputational hits as a result." Very true, and a point worth making. Just curious, do you work closely with SGX/SEV? You were quick with the links!

anonymousDan 6y ago

SEV is fundamentally less secure than SGX because it only provides memory encryption but no integrity protection. Enclaves are a challenging problem given the much more aggressive threat model, but SGX is the better security model of the two IMO.

lima 6y ago
Yes - in a recent paper by Wilke et al[0], they nicely demonstrate how the lack of integrity checking can be exploited. SEV is a very new technology and its current (and previous) iterations have known weaknesses. The next generation of SEV will likely have SEV-SNP[1], which will prevent the host from writing guest memory/messing with the guest's page mappings. Will probably take a few more iterations to stabilize. At that point, it should provide decent security guarantees. Current-gen SGX has much stronger guarantees (conceptually, at least) with full memory integrity checking and less attack surface, but it suffers from CPU vulnerabilities, most of which AMD didn't have, and the integrity checks and architecture come at a large performance and development cost. SEV has different tradeoffs that make it much more useful for real-world use cases, while still providing strong security guarantees. [0]: https://arxiv.org/pdf/2004.11071.pdf https://arxiv.org/pdf/2004.11071.pdf [1]: 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...
- anonymousDan 6y ago
  Oh nice, hadn't heard about SNP yet - looks interesting.

lima 6y ago

SEV is exciting because it has a much better cost-to-benefits ratio. It provides useful defense in depth without requiring any changes to the application stack - you can run regular VMs with syscalls, plenty of memory and high-bandwidth IO. SGX, on the other hand, is extremely limited and notoriously hard to target. It's even harder these days - you need specialized compilers and coding techniques to mitigate a number of attacks that can't be fixed by a microcode update. I reckon it's almost impossible to do serious SGX work these days without being under NDA with Intel such that you can work on mitigations during embargoes for the never-ending stream of vulnerabilities.

deleted 6y ago
[deleted]
thu2111 6y ago
SEV is exciting because it has a much better cost-to-benefits ratio. I think that's not actually true. The problem is if you believe SGX "needs" these sorts of defences/mitigations then so does SEV, because SEV VMs are not magically immune to side channel attacks and in fact suffer far more than just micro-architectural side channels because they also leak all disk and memory access patterns, network access patterns and so on. These sorts of side channels aren't the responsibility of any CPU to fix but are remarkably powerful. Sometimes it feels like SGX gets placed under a rather nasty double standard. Enclaves are "hard" because you "must" mitigate side channel attacks. SEV VMs are "easy" because nobody even tries at all. Indeed they cannot try - normal software isn't built to eliminate app level side channels. That's why enclaves are special programs to begin with. If you are happy to use existing non-hardened software though and just take the defence in depth argument, well, no problem - you can use SGX too. There are things like SCONE that let you run existing software inside enclaves. Unlike SEV, SGX is actually fixable when security bugs are found so it's meaningful to talk about using it. SEV has been theatre so far. It's not renewable, there's no equivalent of TCB recovery so nobody bothers trying to attack it because it's already been broken in unfixable ways before.
- yths 6y ago
  You are right about the double standard but using enclaves means restructuring your application. Even SCONE requires porting. SEV gives you the warm and fuzzy feeling that you are doing something to improve security without having to do a lot of work, assuming that your favorite OS version has been ported to run in a "secure" VM.