linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: "Dr. Greg" <greg@enjellic.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: Thu, 20 Feb 2020 21:57:11 +0200	[thread overview]
Message-ID: <20200220195537.GA23349@linux.intel.com> (raw)
In-Reply-To: <20200219162640.GA29921@wind.enjellic.com>

On Wed, Feb 19, 2020 at 10:26:40AM -0600, Dr. Greg wrote:
> On Tue, Feb 18, 2020 at 05:52:47PM +0200, Jarkko Sakkinen wrote:
> 
> Good morning, I hope the day is going well for everyone.
> 
> > On Tue, Feb 18, 2020 at 04:42:43AM -0600, Dr. Greg Wettstein wrote:
> > > 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.
> 
> > Also UDS sockets with SCM_RIGHTS should work.
> 
> The first clarification, I'm assuming you mean passing SCM_RIGHTS over
> AF_UNIX/UNIX-domain sockets, not UDP sockets?

UNIX domain sockets.

> Secondly, it was my understanding that the reason major renovations to
> the driver were initiated, almost a year ago now, was to create a
> situation where there was a filehandle per enclave in order for the
> LSM to get a 'look' at the executable TEXT that was being deployed to
> the enclave.

File handle per enclave was driven by many things, e.g. ability to
access enclave from multiple processes either through forking or UDS
sockets.

LSM specifc changes are not part of the patch set but file handle based
model is adaptable to LSM's later on.

> It appears that the sgx_open() function, that is installed as the
> ->open method for the /dev/sgx/enclave device node, allocates the
> master enclave definition structure, that is installed, and
> subsequently released, as private data for the file instance object.
> This master enclave structure has the reference to the virtual memory
> definition for the enclave that is opened.

You can have multiple references to an enclave by using formentioned
tools.

> This would seem to imply that the driver is rather firmly architected
> on the notion of one open() per enclave, a concept that Jethro seems
> to have issues with.

I don't understand what concept you are talking about.

/Jarkko

  reply	other threads:[~2020-02-20 19:57 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10 11:37 x86/sgx: v23-rc2 Jarkko Sakkinen
2019-10-10 13:37 ` Jarkko Sakkinen
2019-10-10 17:09   ` Sean Christopherson
2019-10-10 17:39     ` Sean Christopherson
2019-10-11 16:37 ` Jethro Beekman
2019-10-11 18:15   ` Sean Christopherson
2019-10-14  8:43     ` Jethro Beekman
2019-10-17 17:57       ` Sean Christopherson
2020-02-13 14:10         ` Jethro Beekman
2020-02-15  7:24           ` Jarkko Sakkinen
2020-02-17  8:52             ` Jethro Beekman
2020-02-17 18:55               ` Jarkko Sakkinen
2020-02-17 18:56                 ` Jarkko Sakkinen
2020-02-18 10:42                 ` Dr. Greg Wettstein
2020-02-18 15:00                   ` Andy Lutomirski
2020-02-22  3:16                     ` Dr. Greg
2020-02-22  5:41                       ` Andy Lutomirski
2020-03-01 10:42                         ` Dr. Greg
2020-02-23 17:13                       ` Jarkko Sakkinen
2020-02-18 15:52                   ` Jarkko Sakkinen
2020-02-19 16:26                     ` Dr. Greg
2020-02-20 19:57                       ` Jarkko Sakkinen [this message]
2020-02-21  1:19                         ` Dr. Greg
2020-02-21 13:00                           ` Jarkko Sakkinen
2020-03-05 19:51                             ` Sean Christopherson
2020-03-05 20:34                               ` Jethro Beekman
2020-03-05 21:00                                 ` Sean Christopherson
2020-03-06 18:34                               ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200220195537.GA23349@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=greg@enjellic.com \
    --cc=jethro@fortanix.com \
    --cc=linux-sgx@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=sean.j.christopherson@intel.com \
    --cc=serge.ayoun@intel.com \
    --cc=shay.katz-zamir@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).