All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Nathaniel McCallum <npmccallum@redhat.com>,
	Cedric Xing <cedric.xing@intel.com>,
	Jethro Beekman <jethro@fortanix.com>,
	Andy Lutomirski <luto@amacapital.net>,
	linux-sgx@vger.kernel.org
Subject: Re: [PATCH for_v29 v2 1/5] x86/sgx: vdso: Make __vdso_sgx_enter_enclave() callable from C code
Date: Fri, 17 Apr 2020 21:57:42 +0300	[thread overview]
Message-ID: <20200417185742.GA42307@linux.intel.com> (raw)
In-Reply-To: <20200417150501.GD13233@linux.intel.com>

On Fri, Apr 17, 2020 at 08:05:01AM -0700, Sean Christopherson wrote:
> On Tue, Mar 31, 2020 at 12:04:46AM +0300, Jarkko Sakkinen wrote:
> > On Mon, Mar 30, 2020 at 11:08:07AM -0700, Sean Christopherson wrote:
> > > Make __vdso_sgx_enter_enclave() callable from C by preserving %rbx
> > > and taking @leaf in %rcx instead of %rax.  Being able to invoke the vDSO
> > > from C reduces the overhead of runtimes that are tightly coupled with
> > > their enclaves, e.g. that can rely on the enclave to save and restore
> > > non-volatile registers, as the runtime doesn't need an assembly wrapper
> > > to preserve non-volatile registers and/or shuffle stack arguments.
> > > 
> > > Note, both %rcx and %rbx are consumed by EENTER/ERESUME, i.e. consuming
> > > them doesn't violate the primary tenet of __vdso_sgx_enter_enclave()
> > > that "thou shalt not restrict how information is exchanged between an
> > > enclave and its host process".
> > > 
> > > Suggested-by: Nathaniel McCallum <npmccallum@redhat.com>
> > > Cc: Cedric Xing <cedric.xing@intel.com>
> > > Cc: Jethro Beekman <jethro@fortanix.com>
> > > Cc: Andy Lutomirski <luto@amacapital.net>
> > > Cc: linux-sgx@vger.kernel.org
> > > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> > > ---
> > >  arch/x86/entry/vdso/vsgx_enter_enclave.S | 30 ++++++++++++++----------
> > >  1 file changed, 18 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > > index 34cee2b0ef09..c56064fb36bc 100644
> > > --- a/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > > +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > > @@ -17,22 +17,22 @@
> > >  
> > >  /**
> > >   * __vdso_sgx_enter_enclave() - Enter an SGX enclave
> > > + * @rdi:	Pass-through value for RDI
> > > + * @rsi:	Pass-through value for RSI
> > > + * @rdx:	Pass-through value for RDX
> > >   * @leaf:	ENCLU leaf, must be EENTER or ERESUME
> > > + * @r8:		Pass-through value for R8
> > > + * @r9:		Pass-through value for R9
> > >   * @tcs:	TCS, must be non-NULL
> > >   * @e:		Optional struct sgx_enclave_exception instance
> > >   * @handler:	Optional enclave exit handler
> > >   *
> > > - * **Important!**  __vdso_sgx_enter_enclave() is **NOT** compliant with the
> > > - * x86-64 ABI, i.e. cannot be called from standard C code.
> > > - *
> > > - * Input ABI:
> > > - *  @leaf	%eax
> > > - *  @tcs	8(%rsp)
> > > - *  @e 		0x10(%rsp)
> > > - *  @handler	0x18(%rsp)
> > > - *
> > > - * Output ABI:
> > > - *  @ret	%eax
> > > + * **Important!**  __vdso_sgx_enter_enclave() does not ensure full compliance
> > 
> > I'd simply put **NOTE** here instead of **Important!** as it is more
> > common.
> > 
> > > + * with the x86-64 ABI, e.g. doesn't explicitly clear EFLAGS.DF after EEXIT.
> > > + * Except for non-volatile general purpose registers, preserving/setting state
> > > + * in accordance with the x86-64 ABI is the responsibility of the enclave and
> > > + * its runtime, i.e. __vdso_sgx_enter_enclave() cannot be called from C code
> > > + * without careful consideration by both the enclave and its runtime.
> > 
> > Instead "e.g. doesn't explcitly clear EFLAGS.DF after EEXIT" (which is
> > somewhat confusing statement) paragraph should be replaced with a simple
> > enumerated list of differences.
> 
> I don't think the list is that simple, e.g. there is a lot of state that
> is defined by the ABI that isn't touched, IMO talking about that state will
> add confusion.
> 
> I also don't understand what's confusing about stating EFLAGS.DF isn't
> cleared.

Too much time was has passed since the last version, and too many
patches have been reviewed since.

Please just refresh the way you feel best and I will make conclusions
based on that. It's faster that way in the end.

/Jarkko

  reply	other threads:[~2020-04-17 18:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30 18:08 [PATCH for_v29 v2 0/5] x86/sgx: Make vDSO callable from C Sean Christopherson
2020-03-30 18:08 ` [PATCH for_v29 v2 1/5] x86/sgx: vdso: Make __vdso_sgx_enter_enclave() callable from C code Sean Christopherson
2020-03-30 21:04   ` Jarkko Sakkinen
2020-04-17 15:05     ` Sean Christopherson
2020-04-17 18:57       ` Jarkko Sakkinen [this message]
2020-03-30 18:08 ` [PATCH for_v29 v2 2/5] x86/sgx: vdso: Define a typedef for __vdso_sgx_enter_enclave Sean Christopherson
2020-03-30 21:10   ` Jarkko Sakkinen
2020-03-30 18:08 ` [PATCH for_v29 v2 3/5] selftests/sgx: Pass EENTER to vDSO wrapper instead of hardcoding Sean Christopherson
2020-03-30 21:07   ` Jarkko Sakkinen
2020-03-30 21:11     ` Jarkko Sakkinen
2020-03-30 18:08 ` [PATCH for_v29 v2 4/5] selftests/sgx: Stop clobbering non-volatile registers Sean Christopherson
2020-03-30 18:08 ` [PATCH for_v29 v2 5/5] selftests/sgx: Add selftest to invoke __vsgx_enter_enclave() from C Sean Christopherson
2020-03-30 20:48 ` [PATCH for_v29 v2 0/5] x86/sgx: Make vDSO callable " Jarkko Sakkinen
2020-03-30 21:42   ` Nathaniel McCallum
2020-03-31 11:58     ` Jarkko Sakkinen
2020-03-31 13:40       ` Nathaniel McCallum
2020-04-01  8:17         ` Jarkko Sakkinen
2020-04-01 13:06           ` Nathaniel McCallum
2020-04-01 14:49             ` Sean Christopherson
2020-04-02 20:01               ` Jarkko Sakkinen
2020-04-02 19:49             ` 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=20200417185742.GA42307@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=cedric.xing@intel.com \
    --cc=jethro@fortanix.com \
    --cc=linux-sgx@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=npmccallum@redhat.com \
    --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 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.