From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: linux-sgx@vger.kernel.org
Subject: Re: [PATCH for v24 2/3] x86/sgx: Destroy enclave if EADD fails
Date: Tue, 5 Nov 2019 00:31:25 +0200 [thread overview]
Message-ID: <20191104223019.GB3606@linux.intel.com> (raw)
In-Reply-To: <20191104205401.GB5960@linux.intel.com>
On Mon, Nov 04, 2019 at 12:54:01PM -0800, Sean Christopherson wrote:
> On Mon, Nov 04, 2019 at 10:01:40PM +0200, Jarkko Sakkinen wrote:
> > __sgx_encl_add_page() can only fail in the case of EPCM conflict at least
> > in non-artificial situations.
>
> Huh? EADD can fail for a variety of reasons. I can't think of a use case
> where userspace _won't_ kill the enclave in response to failure, but that
> doesn't justify killing the enclave, e.g. we don't kill the enclave in any
> other error path that is just as indicative of a userspace bug.
I think it does because it is the only sane metrics to take and it
also makes the semantics more sound and coherent.
> > Also, it consistent semantics in rollback is something to pursue for.
>
> I don't follow this at all. How is it inconsistent to state that errors
> are handled gracefully unless they're unrecoverable?
Always when the user space gets -EIO it will know that enclave ceased
to exist. That is very consistent.
> > Thus, destroy enclave when the EADD fails as we do when EEXTEND fails
> > already.
> >
> > In the cases it is sane to return -EIO. From this the caller can deduce
> > the failure and knows that the enclave was destroyed. The previous
> > -EFAULT could happen in numerous situations.
>
> This should be a separate patch.
No it shouldn't because it is so closely connected to the semantics
change.
/Jarkko
next prev parent reply other threads:[~2019-11-04 22:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-04 20:01 [PATCH for v24 1/3] x86/sgx: Use GFP_KERNEL for allocations Jarkko Sakkinen
2019-11-04 20:01 ` [PATCH for v24 2/3] x86/sgx: Destroy enclave if EADD fails Jarkko Sakkinen
2019-11-04 20:54 ` Sean Christopherson
2019-11-04 22:31 ` Jarkko Sakkinen [this message]
2019-11-04 20:01 ` [PATCH for v24 3/3] x86/sgx: Remove a subordinate clause Jarkko Sakkinen
2019-11-04 21:21 ` Sean Christopherson
2019-11-04 22:36 ` Jarkko Sakkinen
2019-11-04 22:37 ` Jarkko Sakkinen
2019-11-04 20:46 ` [PATCH for v24 1/3] x86/sgx: Use GFP_KERNEL for allocations Sean Christopherson
2019-11-04 22:26 ` Jarkko Sakkinen
2019-11-05 2:17 ` Sean Christopherson
2019-11-06 21:54 ` Jarkko Sakkinen
2019-11-06 21:59 ` Jarkko Sakkinen
2019-11-06 22:02 ` 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=20191104223019.GB3606@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=linux-sgx@vger.kernel.org \
--cc=sean.j.christopherson@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).