[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6c1b7424-84f6-5fd4-ed7f-6c326d0e4090@intel.com>
Date: Tue, 6 Nov 2018 09:00:38 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Sean Christopherson <sean.j.christopherson@...el.com>,
Andy Lutomirski <luto@...nel.org>, Jann Horn <jannh@...gle.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Rich Felker <dalias@...c.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Jethro Beekman <jethro@...tanix.com>,
Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
Florian Weimer <fweimer@...hat.com>,
Linux API <linux-api@...r.kernel.org>, X86 ML <x86@...nel.org>,
linux-arch <linux-arch@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>, nhorman@...hat.com,
npmccallum@...hat.com, "Ayoun, Serge" <serge.ayoun@...el.com>,
shay.katz-zamir@...el.com, linux-sgx@...r.kernel.org,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Carlos O'Donell <carlos@...hat.com>,
adhemerval.zanella@...aro.org
Subject: Re: RFC: userspace exception fixups
On 11/6/18 7:37 AM, Sean Christopherson wrote:
>
> void *sgx_alloc_untrusted_stack(size_t size)
> {
> struct sgx_encl_tls *tls = get_encl_tls();
> struct sgx_out_call_context *context;
> void *tmp;
>
> /* create a frame on the trusted stack to hold the out-call context */
> tls->trusted_stack -= sizeof(struct sgx_out_call_context);
>
> /* save the untrusted %RSP into the out-call context */
> context = (struct sgx_out_call_context *)tls->trusted_stack;
> context->untrusted_stack = tls->save_state_area[SSA_RSP];
>
> /* allocate space on the untrusted stack */
> tmp = (void *)(tls->save_state_area[SSA_RSP] - size);
> tls->save_state_area[SSA_RSP] = tmp;
>
> return tmp;
> }
Why does it bother to go to all the trouble of mucking with the
untrusted stack? It could *easily* just leave it alone and do out-calls
if it needs to allocate memory for parameter storage. Heck, that could
theoretically even be _on_ the stack if the untrusted runtime was being
clever.
The only downside would be that the untrusted runtime would have to keep
track of the space a bit more explicitly so it could be cleaned up if
the enclave didn't do it.
Powered by blists - more mailing lists