linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Andy 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>,
	linux-sgx@vger.kernel.org, haitao.huang@linux.intel.com,
	Jethro Beekman <jethro@fortanix.com>,
	"Dr. Greg Wettstein" <greg@enjellic.com>
Subject: Re: [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions
Date: Fri, 7 Dec 2018 11:23:10 -0800	[thread overview]
Message-ID: <EFA99261-BE93-49DA-9A8F-E6FD28069AFC@amacapital.net> (raw)
In-Reply-To: <20181207190257.GC10404@linux.intel.com>


> On Dec 7, 2018, at 11:02 AM, Sean Christopherson <sean.j.christopherson@intel.com> wrote:
> 
>> On Fri, Dec 07, 2018 at 09:56:09AM -0800, Andy Lutomirski wrote:
>> On Fri, Dec 7, 2018 at 8:51 AM Sean Christopherson
>> <sean.j.christopherson@intel.com> wrote:
>>> I like that the exit handler allows userspace to trap/panic with the full
>>> call stack in place, and in a dedicated path, i.e. outside of the basic
>>> enter/exit code.  An exit handler probably doesn't fundamentally change
>>> what userspace can do with respect to debugging/reporting, but I think
>>> it would actually simplify some userspace implementations, e.g. I'd use
>>> it in my tests like so:
>>> 
>>> long fault_handler(struct sgx_enclave_exit_info *exit_info, void *tcs, void *priv)
>>> {
>>>        if (exit_info->leaf == SGX_EEXIT)
>>>                return 0;
>>> 
>>>        <report exception and die/hang>
>>> }
>>> 
>> 
>> Hmm.  That't not totally silly, although you could accomplish almost
>> the same thing by wrapping the vDSO helper in another function.
> 
> True, but I think there's value in having the option to intercept an
> exception at the exact(ish) point of failure, without having to return
> up the stack.
> 
> The enclave has full access to the process' memory space, including the
> untrsuted stack.  It's not too far fetched to envision a scenario where
> the enclave corrupts the stack even if the enclave isn't intentionally
> using the stack, e.g. the host passes in variable that a points at the
> stack instead of whatever memory is supposed to be shared between the
> enclave and host.  It'd be nice to have the ability to triage something
> like that without having to e.g. configure breakpoints on the stack.

Ah, I see. You’re saying that, if the non-enclave stare is corrupted such that RIP  is okay and RSP still points somewhere reasonable but the return address is garbage, then we can at least get to the fault handler and print something?  This only works if the fault handler pointer itself is okay, though, which somewhat limits the usefulness, given that its pointer is quite likely to be on the stack very close to the return address.

I really wish the ENCLU instruction had seen fit to preserve some registers.

  reply	other threads:[~2018-12-07 19:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20181206221922.31012-1-sean.j.christopherson@intel.com>
     [not found] ` <20181206221922.31012-5-sean.j.christopherson@intel.com>
     [not found]   ` <CALCETrXRJ645=08fyeoMQ949fLB1TvhsgERFVx5mAHdViEjq8Q@mail.gmail.com>
2018-12-07 16:51     ` [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions Sean Christopherson
2018-12-07 17:56       ` Andy Lutomirski
2018-12-07 19:02         ` Sean Christopherson
2018-12-07 19:23           ` Andy Lutomirski [this message]
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 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
     [not found]   ` <20181207163127.GA23494@wind.enjellic.com>
2018-12-07 18:19     ` 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=EFA99261-BE93-49DA-9A8F-E6FD28069AFC@amacapital.net \
    --to=luto@amacapital.net \
    --cc=bp@alien8.de \
    --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@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).