linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Borislav Petkov <bp@alien8.de>,
	Jethro Beekman <jethro@fortanix.com>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	"Christopherson, Sean J" <sean.j.christopherson@intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Can we credibly make vdso_sgx_enter_enclave() pleasant to use?
Date: Fri, 25 Sep 2020 09:55:00 -0700	[thread overview]
Message-ID: <CALCETrUhQjQQa-BqNHPgdDfD9GDJZXJWSQ_M0tDF_ri5RfyTsw@mail.gmail.com> (raw)

vdso_sgx_enter_enclave() sucks. I don't think anyone seriously likes
it, but maybe it's the best we can do.

I'm wondering if it's worth trying to do better.  Here's what I'd like
if I could wave a magic wand:

struct sgx_enclave_run {
       __u64 tcs;
       __u32 flags;
       __u32 exit_reason;

    /*
     * These values are exposed to the enclave on entry, and the values
     * left behind by the enclave are returned here.
     * Some enclaves might write to memory pointed to by rsp.
     */
       __u64 rsp, rbp, r8, r9, r10, r11, r12, r13, r14, r15;
       /* Maybe other regs too? */

       union {
               struct sgx_enclave_exception exception;

               /* Pad the entire struct to 256 bytes. */
               __u8 pad[256 - 32];
       };
};

long vdso_sgx_enter_enclave(unsigned int leaf, struct sgx_enclave_run *r);

No callback, no asm wrapper needed, no nastiness from the perspective
of the caller.

So here are my questions.  First, do people agree with me that this
would be better?  Second, could this be implemented in a way that
doesn't utterly suck?  The best I've come up with so far is abusing
WRFSBASE to shove a little data structure containing the real user RSP
or RBP along with the old FSBASE into FSBASE, do EENTER, and then undo
the FSBASE dance.  We'd also need some additional exception fixup
magic to prevent a signal or ptrace() from observing the intermediate
states and getting extremely confused.

--Andy

             reply	other threads:[~2020-09-25 16:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25 16:55 Andy Lutomirski [this message]
2020-09-25 19:09 ` Can we credibly make vdso_sgx_enter_enclave() pleasant to use? Sean Christopherson
2020-09-25 20:20   ` Andy Lutomirski
2020-09-25 22:29     ` Sean Christopherson
2020-09-26 19:05       ` Andy Lutomirski
2020-09-26 23:55         ` Xing, Cedric
2020-09-26  9:27 ` Jethro Beekman

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=CALCETrUhQjQQa-BqNHPgdDfD9GDJZXJWSQ_M0tDF_ri5RfyTsw@mail.gmail.com \
    --to=luto@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jethro@fortanix.com \
    --cc=linux-kernel@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).