linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: "Christopherson, Sean J" <sean.j.christopherson@intel.com>
Cc: Andrew Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	X86 ML <x86@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Josh Triplett <josh@joshtriplett.org>
Subject: Re: [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions
Date: Thu, 6 Dec 2018 14:50:01 -0800	[thread overview]
Message-ID: <CALCETrXRJ645=08fyeoMQ949fLB1TvhsgERFVx5mAHdViEjq8Q@mail.gmail.com> (raw)
In-Reply-To: <20181206221922.31012-5-sean.j.christopherson@intel.com>

On Thu, Dec 6, 2018 at 2:19 PM Sean Christopherson
<sean.j.christopherson@intel.com> wrote:
>
 +
> +       /*
> +        * Invoke the caller's exit handler if one was provided.  The return
> +        * value tells us whether to re-enter the enclave (EENTER or ERESUME)
> +        * or to return (EEXIT).
> +        */
> +       if (exit_handler) {
> +               leaf = exit_handler(exit_info, tcs, priv);
> +               if (leaf == SGX_EENTER || leaf == SGX_ERESUME)
> +                       goto enter_enclave;
> +               if (leaf == SGX_EEXIT)
> +                       return 0;
> +               return -EINVAL;
> +       } else if (leaf != SGX_EEXIT) {
> +               return -EFAULT;
> +       }

This still seems overcomplicated to me.  How about letting the
requested leaf (EENTER or ERESUME) be a parameter to the function and
then just returning here?  As it stands, you're requiring any ERESUME
that gets issued (other than the implicit ones) to be issued in the
same call stack, which is very awkward if you're doing something like
forwarding the fault to a different task over a socket and then
waiting in epoll_wait() or similar before resuming the enclave.

--Andy

  reply	other threads:[~2018-12-06 22:50 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06 22:19 [RFC PATCH v2 0/4] x86: Add vDSO exception fixup for SGX Sean Christopherson
2018-12-06 22:19 ` [RFC PATCH v2 1/4] x86/vdso: Add support for exception fixup in vDSO functions Sean Christopherson
2018-12-06 22:19 ` [RFC PATCH v2 2/4] x86/fault: Attempt to fixup unhandled #PF in vDSO before signaling Sean Christopherson
2018-12-06 22:19 ` [RFC PATCH v2 3/4] x86/traps: Attempt to fixup exceptions " Sean Christopherson
2018-12-06 22:19 ` [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions Sean Christopherson
2018-12-06 22:50   ` Andy Lutomirski [this message]
2018-12-07 16:51     ` Sean Christopherson
2018-12-07 17:56       ` Andy Lutomirski
2018-12-07 19:02         ` Sean Christopherson
2018-12-07 19:23           ` Andy Lutomirski
2018-12-07 20:09             ` Sean Christopherson
2018-12-07 20:16               ` Andy Lutomirski
2018-12-07 20:35                 ` Sean Christopherson
2018-12-07 21:26                 ` Sean Christopherson
2018-12-07 23:33                   ` Andy Lutomirski
2018-12-11 19:31                     ` Sean Christopherson
2018-12-11 20:04                       ` Andy Lutomirski
2018-12-11 22:00                         ` Sean Christopherson
2018-12-11 23:12                           ` Andy Lutomirski
2018-12-07 16:31   ` Dr. Greg
2018-12-07 18:05     ` Andy Lutomirski
2018-12-07 18:19     ` Jethro Beekman
2018-12-07 18:15   ` Jethro Beekman
2018-12-07 18:44     ` Dave Hansen
2018-12-07 18:50       ` Andy Lutomirski
2018-12-08  8:15       ` Jethro Beekman
2018-12-14 15:04         ` Sean Christopherson

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='CALCETrXRJ645=08fyeoMQ949fLB1TvhsgERFVx5mAHdViEjq8Q@mail.gmail.com' \
    --to=luto@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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).