Re: [PATCH v20 00/28] Intel SGX1 support
From: Dr. Greg
Date: Tue Apr 23 2019 - 05:12:28 EST
On Mon, Apr 22, 2019 at 10:17:15AM -0700, Sean Christopherson wrote:
Good morning to everyone.
> On Mon, Apr 22, 2019 at 09:55:47AM -0700, Linus Torvalds wrote:
> > On Mon, Apr 22, 2019 at 9:48 AM Sean Christopherson
> > <sean.j.christopherson@xxxxxxxxx> wrote:
> > >
> > > Right, and loading a malicious enclave doesn't change those guarantees
> > > (for other enclaves). Ergo, restricting which enclaves can execute is
> > > orthogonal to the security provided by SGX.
> >
> > But it is absolutely worth noting that TSX made a lot of attacks both
> > easier to _do_, and also easier to _hide_.
> >
> > All while being basically completely worthless technology to everybody
> > except for some silly SAP benchmark.
> >
> > So it is definitely worth at least discussing the downsides of SGX. If
> > it ends up being another technology that makes it easier to create
> > malware, without actually having a lot of _good_ software use it, the
> > patches to enable it should make damn sure that the upsides actually
> > outweigh the downsides.
> >
> > And if the current setup basically is "you have to disable reasonable
> > SElinux protections that lots of distros use today", I think it's
> > entirely reasonable saying "the downsides are bigger than the
> > upsides".
> I'm not arguing against SGX playing nice with SELinux/LSMs, actually
> the opposite. I completely agree that enclaves should be subject to
> LSM restrictions.
As do we.
The point we have been making is that depending on the LSM's are
depending on the fact that the platform has not been compromised. SGX
is designed to provide a trusted execution environment in the face of
a compromised platform.
> AIUI, Dr. Greg is proposing a framework that uses SGX's launch
> control mechanism to restrict what enclaves can run. My point is
> that restricting what enclaves can run is about protecting the
> kernel and/or platform, not the enclaves themselves, i.e. using
> launch control instead of, or in addition to, LSMs doesn't change
> the security guarantees of SGX.
I believe current research suggests that this is not the case.
>From the paper we have previously cited:
https://arxiv.org/pdf/1702.08719.pdf
In the second paragraph of the abstract:
"In this paper, we demonstrate fine-grained software-based
side-channel attacks from a malicious SGX enclave targeting co-located
enclaves. Our attack is the first malware running on real SGX
hardware, abusing SGX protection features to conceal itself.
Furthermore, we demonstrate our attack both in a native environment
and across multiple Docker containers".
To be perfectly clear, Dr. Greg, technically IDfusion, is not
proposing the use of SGX's launch control to restrict which enclaves
can run, although there are perfectly legitimate and required use
cases for that technology.
Dr. Greg is proposing that the kernel driver expend 1.2 pages of
kernel memory to implement, at the discretion of the platform owner,
cryptographically verified enclave initialization. The design we
proposed is the strongest guarantee that a platform owner can
implement, on FLC hardware, that only code and data of known
provenance can be loaded and executed.
There are only two companies that have written the entire stack of
software needed to make practical SGX applications work, us and Intel.
We can go into intimate detail on the issues involved but will embrace
bevity at this point.
Have a good day.
Dr. Greg
As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N. 19th Ave. Specializing in information infra-structure
Fargo, ND 58102 development.
PH: 701-281-1686
FAX: 701-281-3949 EMAIL: greg@xxxxxxxxxxxx
------------------------------------------------------------------------------
"Because the innovator has for enemies all those who have done well
under the old conditions, and lukewarm defenders in those who may do
well under the new."
-- Niccolo Machiavelli
_The Prince_, Chapter VI