Re: Implications of SGAxe?
Thanks for the explanations everyone! And a blog post sounds like a great idea. On Wed, 10 Jun 2020 at 17:50, Mingshen Sun wrote: > > BTW, maybe we can write a blog about the implication of recent side > channel attacks in SGX. But we need some time to survey this problem > and collect enough materials. > > On Wed, Jun 10, 2020 at 3:18 PM Mingshen Sun wrote: > > > > Hi Matt, > > > > Thanks for bringing up this issue. Regardless of this specific attack > > itself, let me answer another frequently asked question about > > supporting other hardware enclaves. > > > > Actually, we have investigated other hardware enclaves for a long > > time. The following are commonly mentioned hardware TEE > > implementations: > > > > - Intel SGX > > - AMD SEV > > - ARM TrustZone > > - RISC-V Keystone > > > > From our experience, Intel SGX provides better security guarantees > > memory encryption/integrity. Also it is more mature in terms of > > ecosystem including toolchains, documents, community, etc. Sadly, > > because of various reasons, they all somehow suffer from side channel > > attacks. Luckly, there are mitigation methods for these attacks. > > > > To answer the question, yes, we do want to support other hardware TEE > > implementations and provide different choices for users/developers. I > > believe as the time goes on, other TEE implementations will become > > mature eventually. Before that, we plan to spend more time on > > implementing the platform itself: providing better interfaces, > > improving functionalities of services, defining the work flow, etc. In > > the meantime, we should also design the system with better > > abstraction with layers so that once things are ready, we can support > > other platforms. > > > > Best, > > Mingshen Sun > > > > On Wed, Jun 10, 2020 at 1:50 PM Yu Ding wrote: > > > > > > From what I understand, SGAxe is still utilizing TSX to leak data from > > > LFB. > > > It's not a problem of SGX, but a problem of TSX. TSX breaks the security > > > guarantees provided by SGX, or VMX. > > > > > > The TSX problem is not limited to attacking SGX, but also stealing memory > > > from Dom0 in Xen, or memory from the kernel of Host OS. To solve this > > > problem, TSX needs to be completely removed/disabled. It's a long-existing > > > problem. Intel tried to remove TSX from a couple of commercial SKUs but > > > haven't done it completely. > > > > > > Best, > > > Yu > > > > > > On Wed, Jun 10, 2020 at 7:43 AM Matt Sicker wrote: > > > > > > > https://cacheoutattack.com/ > > > > > > > > With all these practical attacks in place for Intel (and AMD to a > > > > different extent), what do you think the future of SGX and its > > > > competitors will look like? Are there plans on supporting other > > > > hardware enclaves that may be more secure (if they exist)? > > > > > > > > -- > > > > Matt Sicker > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org > > > > For additional commands, e-mail: dev-h...@teaclave.apache.org > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org > For additional commands, e-mail: dev-h...@teaclave.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org For additional commands, e-mail: dev-h...@teaclave.apache.org
Re: Implications of SGAxe?
Hi Matt, Thanks for bringing up this issue. Regardless of this specific attack itself, let me answer another frequently asked question about supporting other hardware enclaves. Actually, we have investigated other hardware enclaves for a long time. The following are commonly mentioned hardware TEE implementations: - Intel SGX - AMD SEV - ARM TrustZone - RISC-V Keystone >From our experience, Intel SGX provides better security guarantees memory encryption/integrity. Also it is more mature in terms of ecosystem including toolchains, documents, community, etc. Sadly, because of various reasons, they all somehow suffer from side channel attacks. Luckly, there are mitigation methods for these attacks. To answer the question, yes, we do want to support other hardware TEE implementations and provide different choices for users/developers. I believe as the time goes on, other TEE implementations will become mature eventually. Before that, we plan to spend more time on implementing the platform itself: providing better interfaces, improving functionalities of services, defining the work flow, etc. In the meantime, we should also design the system with better abstraction with layers so that once things are ready, we can support other platforms. Best, Mingshen Sun On Wed, Jun 10, 2020 at 1:50 PM Yu Ding wrote: > > From what I understand, SGAxe is still utilizing TSX to leak data from LFB. > It's not a problem of SGX, but a problem of TSX. TSX breaks the security > guarantees provided by SGX, or VMX. > > The TSX problem is not limited to attacking SGX, but also stealing memory > from Dom0 in Xen, or memory from the kernel of Host OS. To solve this > problem, TSX needs to be completely removed/disabled. It's a long-existing > problem. Intel tried to remove TSX from a couple of commercial SKUs but > haven't done it completely. > > Best, > Yu > > On Wed, Jun 10, 2020 at 7:43 AM Matt Sicker wrote: > > > https://cacheoutattack.com/ > > > > With all these practical attacks in place for Intel (and AMD to a > > different extent), what do you think the future of SGX and its > > competitors will look like? Are there plans on supporting other > > hardware enclaves that may be more secure (if they exist)? > > > > -- > > Matt Sicker > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org > > For additional commands, e-mail: dev-h...@teaclave.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org For additional commands, e-mail: dev-h...@teaclave.apache.org
Re: Implications of SGAxe?
>From what I understand, SGAxe is still utilizing TSX to leak data from LFB. It's not a problem of SGX, but a problem of TSX. TSX breaks the security guarantees provided by SGX, or VMX. The TSX problem is not limited to attacking SGX, but also stealing memory from Dom0 in Xen, or memory from the kernel of Host OS. To solve this problem, TSX needs to be completely removed/disabled. It's a long-existing problem. Intel tried to remove TSX from a couple of commercial SKUs but haven't done it completely. Best, Yu On Wed, Jun 10, 2020 at 7:43 AM Matt Sicker wrote: > https://cacheoutattack.com/ > > With all these practical attacks in place for Intel (and AMD to a > different extent), what do you think the future of SGX and its > competitors will look like? Are there plans on supporting other > hardware enclaves that may be more secure (if they exist)? > > -- > Matt Sicker > > - > To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org > For additional commands, e-mail: dev-h...@teaclave.apache.org > >
Implications of SGAxe?
https://cacheoutattack.com/ With all these practical attacks in place for Intel (and AMD to a different extent), what do you think the future of SGX and its competitors will look like? Are there plans on supporting other hardware enclaves that may be more secure (if they exist)? -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org For additional commands, e-mail: dev-h...@teaclave.apache.org