All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Jethro Beekman <jethro@fortanix.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"x86@kernel.org" <x86@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Haitao Huang <haitao.huang@linux.intel.com>,
	"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
	"Dr. Greg" <greg@enjellic.com>
Subject: Re: [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions
Date: Fri, 14 Dec 2018 07:04:37 -0800	[thread overview]
Message-ID: <20181214150436.GA23255@linux.intel.com> (raw)
In-Reply-To: <f595c046-682c-0d4a-ce68-44d4634cedf2@fortanix.com>

On Sat, Dec 08, 2018 at 08:15:38AM +0000, Jethro Beekman wrote:
> On 2018-12-08 00:14, Dave Hansen wrote:
> >On 12/7/18 10:15 AM, Jethro Beekman wrote:
> >>This is not sufficient to support the Fortanix SGX ABI calling
> >>convention, which was designed to be mostly compatible with the SysV
> >>64-bit calling convention. The following registers need to be passed in
> >>to an enclave from userspace: RDI, RSI, RDX, R8, R9, R10. The following
> >>registers need to be passed out from an enclave to userspace: RDI, RSI,
> >>RDX, R8, R9.
> >
> >Are you asking nicely to change the new Linux ABI to be consistent with
> >your existing ABI?  Or, are you saying that the new ABI *must* be
> >compatible with this previous out-of-tree implementation?
> 
> What's being discussed here is one of the alternatives for SGX fault
> handling, meant to improve the current status quo of having to use a signal
> handler.
> 
> I'm merely providing a data point that the currently proposed solution is
> not sufficient to support current use of the (ring 3) ENCLU instruction. You
> might find this useful in determining whether proposed kernel features will
> actually be used by users, and in further developing this solution or other
> solutions to the fault handling issue.
> 
> If going with the vDSO solution, I think something with semantics closer to
> the actual instruction would be preferred, like the following:
> 
> notrace __attribute__((naked)) long __vdso_sgx_enclu_with_aep()
> {
> 	asm volatile(
> 		"	lea	2f(%%rip), %%rcx\n"
> 		"1:	enclu\n"
> 		"2:     ret\n"
> 		".pushsection .fixup, \"ax\" \n"
> 		"3:	jmp 2b\n"
> 		".popsection\n"
> 		_ASM_VDSO_EXTABLE_HANDLE(1b, 3b)
> 		:::
> 	);
> }

Part of me likes this idea, but it's a documentation nightmare since
it's a completely customer register ABI.  And the caller's exception
handling gets a bit weird since RAX implicitly defines whether or not
an exception occurred.  I also think there's value in making the vDSO
function callable from standard C.

      reply	other threads:[~2018-12-14 15:04 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
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 [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=20181214150436.GA23255@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=greg@enjellic.com \
    --cc=haitao.huang@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jethro@fortanix.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --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 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.