From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: linux-sgx@vger.kernel.org, Huang Haitao <haitao.huang@intel.com>
Subject: Re: [PATCH] x86/sgx: Fix double-free when EADD fails
Date: Fri, 13 Dec 2019 01:59:33 +0200 [thread overview]
Message-ID: <20191212235933.GC7854@linux.intel.com> (raw)
In-Reply-To: <20191211160755.GD5044@linux.intel.com>
On Wed, Dec 11, 2019 at 08:07:55AM -0800, Sean Christopherson wrote:
> On Wed, Dec 11, 2019 at 01:11:52PM +0200, Jarkko Sakkinen wrote:
> > On Mon, Dec 09, 2019 at 12:52:55PM -0800, Sean Christopherson wrote:
> > > Not a fan of making this dependent on -EIO, IMO invalidating iff EEXTEND
> > > fails is cleaner. In other words, I still think killing the enclave on
> > > on EADD failure is unnecessary.
> >
> > This comes down to whether you consider them as a transaction. I do
> > and it makes a coherent API.
>
> What's your definition of transaction in this context? My interpretation
> of transaction here would be that each ioctl() should either succeed, fail
> without modifying persistent (enclave) state, or fail and kill the enclave
> (because its state modifications are irreversible).
>
> EEXTEND falls into the last case because EADD can't be unwound. EADD falls
> into the middle case because everything up to EADD can be cleanly undone.
My definition is that if any of EADD/EEXTEND fails the enclave
should be killed as there is no good reason to support that kind
of use in any possible way. As long as it is documented, it is
fine.
/Jarkko
prev parent reply other threads:[~2019-12-12 23:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-05 10:01 [PATCH] x86/sgx: Fix double-free when EADD fails Jarkko Sakkinen
2019-12-09 20:52 ` Sean Christopherson
2019-12-11 11:11 ` Jarkko Sakkinen
2019-12-11 16:07 ` Sean Christopherson
2019-12-12 23:59 ` Jarkko Sakkinen [this message]
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=20191212235933.GC7854@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=haitao.huang@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).