Re: x86/sgx: v23-rc2

From: "Dr. Greg Wettstein" <gw@idfusion.org>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Jethro Beekman <jethro@fortanix.com>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
	"serge.ayoun@intel.com" <serge.ayoun@intel.com>,
	"shay.katz-zamir@intel.com" <shay.katz-zamir@intel.com>
Subject: Re: x86/sgx: v23-rc2
Date: Tue, 18 Feb 2020 04:42:43 -0600	[thread overview]
Message-ID: <20200218104243.GA13967@wind.enjellic.com> (raw)
In-Reply-To: <20200217185512.GA7677@linux.intel.com>

On Mon, Feb 17, 2020 at 08:55:26PM +0200, Jarkko Sakkinen wrote:

Good morning, I hope the week is starting well for everyone.

> On Mon, Feb 17, 2020 at 09:52:25AM +0100, Jethro Beekman wrote:
> > On 2020-02-15 08:24, Jarkko Sakkinen wrote:
> > > On Thu, Feb 13, 2020 at 03:10:24PM +0100, Jethro Beekman wrote:
> > >>>> There are other scenarios where it's not just the permissions on
> > >>>> /dev/sgx/enclave that are the problem but using the filesystem in general
> > >>>> that is. Maybe you've used seccomp to disable file operations, etc.
> > >>>
> > >>> Andy and Jarkko, thoughts?
> > >>
> > >> Folks, any more thoughts on how to resolve the issue that you need to
> > >> call open() for every enclave?
> > > 
> > > Why is it an issue?
> > 
> > Already discussed in https://www.spinics.net/lists/linux-sgx/msg02075.html

I believe an accurate summary of Dr. Beekman's concerns are as
follows:

1.) He envisions a need for an enclave orchestrator that uses root
privileges to open the SGX driver device and then drop privileges,
presumably in a permanent fashion.  The orchestrator would then use
the filehandle to load and initialize multiple enclaves on request.

2.) The enclave orchestrator may be run in an environment that has
SECCOMP limitations on the ability to conduct filesystem operations.

> Not everyone has to have access to open /dev/sgx/enclave in order to
> use enclaves.

That depends on the architecture of the runtime.

The Intel PSW has a model where the AESM daemon orchestrates
activities for applications that wish to use enclaves.

Our Secure Runtime Development Environment (SRDE), on the other hand,
uses a model where each application independently manages its use of
enclaves.  In our model, the SGX driver needs to be accessible by
whatever privilege level an application chooses to run at.

As a result of this model, our SRDE has around an order of magnitude
less complexity then the AESM model and virtually no external
dependencies.  At last count the AESM depends on about 35 separate
shared library systems.

Our model allows us to build applications that are statically linked
and completely self-contained.  A concept of reasonable utility for
containerized environments and embedded systems.  We also avoid C++
that allows us to build MUSL based security stacks.

> It is as much a problem as for practically any driver that provides
> devices for some use.

The only customers of this driver are the runtime developers and that
is currently an extremely limited spectrum of users.

I will concede that I don't understand the SECCOMP issue.  Jethro may
or may not be able to discuss an architecture that would not have
basic filesystem operations available to it.

The fundamental issue, that there appears to be a reluctance to
discuss, is that DAC/MAC controls are not relevant to SGX,
particularly SGX2 based systems, which is what most of this stuff
will be running on.

> /Jarkko

Have a good day.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D    Worker / Principal Engineer
IDfusion, LLC
4206 19th Ave N.            Specialists in SGX secured infrastructure.
Fargo, ND  58102
PH: 701-281-1686            CELL: 701-361-2319
EMAIL: gw@idfusion.org
------------------------------------------------------------------------------
"... remember that innovation is saying 'no' to 1000 things."
                                -- Moxie Marlinspike