All of lore.kernel.org
 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: Fri, 21 Feb 2020 15:00:31 +0200	[thread overview]
Message-ID: <20200221130009.GB3112@linux.intel.com> (raw)
In-Reply-To: <20200221011913.GA15165@wind.enjellic.com>

On Thu, Feb 20, 2020 at 07:19:13PM -0600, Dr. Greg wrote:
> > > 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.
> 
> If memory serves me correctly, Jethro envisioned a model where a
> single open of the SGX driver node would return a file descriptor that
> could then be used to create/load/initialize multiple enclaves.  Your
> clarifications indicate that a separate open will be needed for each
> and every enclave instance that will be orchestrated.
> 
> Jethro, if I'm mistating your position on this, please jump in and
> clarify.

Ah.

You are speaking about having a factory to create enclaves and a
management interface. I.e. you'd have ioctl to create enclave that gives
you a file descriptor to access its management interface.

Out of top of my head I cannot recall why this was not favored in the
end but generally speaking added complexity should be justified by some
considerably strong measures.

/Jarkko

  reply	other threads:[~2020-02-21 13:00 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
2020-02-21  1:19                         ` Dr. Greg
2020-02-21 13:00                           ` Jarkko Sakkinen [this message]
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=20200221130009.GB3112@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.