Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CALCETrUhQjQQa-BqNHPgdDfD9GDJZXJWSQ_M0tDF_ri5RfyTsw@mail.gmail.com>
 <20200925190915.GD31528@linux.intel.com> <CALCETrWDgb_mVPDmKy_7oFg03cOxO-GAUS8kOFrfGiPp9RjboA@mail.gmail.com>
 <20200925222938.GI31528@linux.intel.com>
In-Reply-To: <20200925222938.GI31528@linux.intel.com>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Sat, 26 Sep 2020 12:05:26 -0700
Message-ID: <CALCETrUV-cx6dii2cOcav01GSdo9qx6+GYeoPH9nHMXwg-geQQ@mail.gmail.com>
Subject: Re: Can we credibly make vdso_sgx_enter_enclave() pleasant to use?
To:     Sean Christopherson <sean.j.christopherson@intel.com>
Cc:     Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
        Jethro Beekman <jethro@fortanix.com>,
        Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Nathaniel McCallum <npmccallum@redhat.com>,
        Cedric Xing <cedric.xing@intel.com>, linux-sgx@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Sep 25, 2020 at 3:29 PM Sean Christopherson
<sean.j.christopherson@intel.com> wrote:
>
> On Fri, Sep 25, 2020 at 01:20:03PM -0700, Andy Lutomirski wrote:
> > On Fri, Sep 25, 2020 at 12:09 PM Sean Christopherson
> > <sean.j.christopherson@intel.com> wrote:
> > > But where would the vDSO get memory for that little data structure?  It can't
> > > be percpu because the current task can get preempted.  It can't be per instance
> > > of the vDSO because a single mm/process can have multiple tasks entering an
> > > enclave.  Per task might work, but how would the vDSO get that info?  E.g.
> > > via a syscall, which seems like complete overkill?
> >
> > The stack.
>
> Duh.
>
> > The vDSO could, logically, do:
> >
> > struct sgx_entry_state {
> >   unsigned long real_rbp;
> >   unsigned long real_rsp;
> >   unsigned long orig_fsbase;
> > };
> >
> > ...
> >
> >   struct sgx_entry_state state;
> >   state.rbp = rbp;  [ hey, this is pseudocode.  the real code would be in asm.]
> >   state.rsp = rsp;
> >   state.fsbase = __rdfsbase();
> >   rbp = arg->rbp;
> >
> >   /* set up all other regs */
> >   wrfsbase %rsp
> >   movq enclave_rsp(%rsp), %rsp
>
> I think this is where there's a disconnect with what is being requested by the
> folks writing run times.  IIUC, they want to use the untrusted runtime's stack
> to pass params because it doesn't require additional memory allocations and
> automagically grows as necessary (obviously to a certain limit).  I.e. forcing
> the caller to provide an alternative "stack" defeats the purpose of using the
> untrusted stack.

I personally find this concept rather distasteful.  Sure, it might
save a couple cycles, but it means that the enclave has hardcoded some
kind of assumption about the outside-the-enclave stack.

Given that RBP seems reasonably likely to be stable across enclave
executions, I suppose we could add a flag and an RSP value in the
sgx_enclave_run structure.  If set, the vDSO would swap out RSP (but
not RBP) with the provided value on entry and record the new RSP on
exit.  I don't know if this would be useful to people.

I do think we need to add at least minimal CFI annotations no matter what we do.