You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@teaclave.apache.org by Matt Sicker <bo...@gmail.com> on 2020/06/10 14:43:31 UTC
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 <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@teaclave.apache.org
For additional commands, e-mail: dev-help@teaclave.apache.org
Re: Implications of SGAxe?
Posted by Matt Sicker <bo...@gmail.com>.
Thanks for the explanations everyone! And a blog post sounds like a great idea.
On Wed, 10 Jun 2020 at 17:50, Mingshen Sun <ms...@apache.org> 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 <ms...@apache.org> 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 <di...@apache.org> 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 <bo...@gmail.com> 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 <bo...@gmail.com>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@teaclave.apache.org
> > > > For additional commands, e-mail: dev-help@teaclave.apache.org
> > > >
> > > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@teaclave.apache.org
> For additional commands, e-mail: dev-help@teaclave.apache.org
>
--
Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@teaclave.apache.org
For additional commands, e-mail: dev-help@teaclave.apache.org
Re: Implications of SGAxe?
Posted by Mingshen Sun <ms...@apache.org>.
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 <ms...@apache.org> 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 <di...@apache.org> 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 <bo...@gmail.com> 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 <bo...@gmail.com>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@teaclave.apache.org
> > > For additional commands, e-mail: dev-help@teaclave.apache.org
> > >
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@teaclave.apache.org
For additional commands, e-mail: dev-help@teaclave.apache.org
Re: Implications of SGAxe?
Posted by Mingshen Sun <ms...@apache.org>.
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 <di...@apache.org> 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 <bo...@gmail.com> 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 <bo...@gmail.com>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@teaclave.apache.org
> > For additional commands, e-mail: dev-help@teaclave.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@teaclave.apache.org
For additional commands, e-mail: dev-help@teaclave.apache.org
Re: Implications of SGAxe?
Posted by Yu Ding <di...@apache.org>.
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 <bo...@gmail.com> 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 <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@teaclave.apache.org
> For additional commands, e-mail: dev-help@teaclave.apache.org
>
>