From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7FA5C0044C for ; Wed, 7 Nov 2018 21:28:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9D36721019 for ; Wed, 7 Nov 2018 21:28:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D36721019 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727567AbeKHHAf (ORCPT ); Thu, 8 Nov 2018 02:00:35 -0500 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:58188 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726659AbeKHHAe (ORCPT ); Thu, 8 Nov 2018 02:00:34 -0500 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1gKVMk-0003R5-00; Wed, 07 Nov 2018 21:27:58 +0000 Date: Wed, 7 Nov 2018 16:27:58 -0500 From: Rich Felker To: Sean Christopherson Cc: Andy Lutomirski , Dave Hansen , Jann Horn , Linus Torvalds , Dave Hansen , Jethro Beekman , Jarkko Sakkinen , Florian Weimer , Linux API , X86 ML , linux-arch , LKML , Peter Zijlstra , nhorman@redhat.com, npmccallum@redhat.com, "Ayoun, Serge" , shay.katz-zamir@intel.com, linux-sgx@vger.kernel.org, Andy Shevchenko , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Carlos O'Donell , adhemerval.zanella@linaro.org Subject: Re: RFC: userspace exception fixups Message-ID: <20181107212758.GU5150@brightrain.aerifal.cx> References: <1541518670.7839.31.camel@intel.com> <1541524750.7839.51.camel@intel.com> <22596E35-F5D1-4935-86AB-B510DCA0FABE@amacapital.net> <20181106231730.GR5150@brightrain.aerifal.cx> <20181106232616.GA11101@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181106232616.GA11101@linux.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 06, 2018 at 03:26:16PM -0800, Sean Christopherson wrote: > On Tue, Nov 06, 2018 at 06:17:30PM -0500, Rich Felker wrote: > > On Tue, Nov 06, 2018 at 11:02:11AM -0800, Andy Lutomirski wrote: > > > On Tue, Nov 6, 2018 at 10:41 AM Dave Hansen wrote: > > > > > > > > On 11/6/18 10:20 AM, Andy Lutomirski wrote: > > > > > I almost feel like the right solution is to call into SGX on its own > > > > > private stack or maybe even its own private address space. > > > > > > > > Yeah, I had the same gut feeling. Couldn't the debugger even treat the > > > > enclave like its own "thread" with its own stack and its own set of > > > > registers and context? That seems like a much more workable model than > > > > trying to weave it together with the EENTER context. > > > > > > So maybe the API should be, roughly > > > > > > sgx_exit_reason_t sgx_enter_enclave(pointer_to_enclave, struct > > > host_state *state); > > > sgx_exit_reason_t sgx_resume_enclave(same args); > > > > > > where host_state is something like: > > > > > > struct host_state { > > > unsigned long bp, sp, ax, bx, cx, dx, si, di; > > > }; > > > > > > and the values in host_state explicitly have nothing to do with the > > > actual host registers. So, if you want to use the outcall mechanism, > > > you'd allocate some memory, point sp to that memory, call > > > sgx_enter_enclave(), and then read that memory to do the outcall. > > > > > > Actually implementing this would be distinctly nontrivial, and would > > > almost certainly need some degree of kernel help to avoid an explosion > > > when a signal gets delivered while we have host_state.sp loaded into > > > the actual SP register. Maybe rseq could help with this? > > > > > > The ISA here is IMO not well thought through. > > > > Maybe I'm mistaken about some fundamentals here, but my understanding > > of SGX is that the whole point is that the host application and the > > code running in the enclave are mutually adversarial towards one > > another. Do any or all of the proposed protocols here account for this > > and fully protect the host application from malicious code in the > > enclave? It seems that having control over the register file on exit > > from the enclave is fundamentally problematic but I assume there must > > be some way I'm missing that this is fixed up. > > SGX provides protections for the enclave but not the other way around. > The kernel has all of its normal non-SGX protections in place, but the > enclave can certainly wreak havoc on its userspace process. The basic > design idea is that the enclave is a specialized .so that gets extra > security protections but is still effectively part of the overall > application, e.g. it has full access to its host userspace process' > virtual memory. In that case it seems like the only way to use SGX that's not a gaping security hole is to run the SGX enclave in its own fully-seccomp (or equivalent) process, with no host application in the same address space. Since the host application can't see the contents of the enclave to make any determination of whether it's safe to run, running it in the same address space only makes sense if the cpu provides protection against unwanted accesses to the host's memory from the enclave -- and according to you, it doesn't. Rich From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 7 Nov 2018 16:27:58 -0500 From: Rich Felker To: Sean Christopherson CC: Andy Lutomirski , Dave Hansen , Jann Horn , Linus Torvalds , Dave Hansen , Jethro Beekman , Jarkko Sakkinen , Florian Weimer , Linux API , X86 ML , linux-arch , LKML , Peter Zijlstra , , , "Ayoun, Serge" , , , Andy Shevchenko , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "Carlos O'Donell" , Subject: Re: RFC: userspace exception fixups Message-ID: <20181107212758.GU5150@brightrain.aerifal.cx> References: <1541518670.7839.31.camel@intel.com> <1541524750.7839.51.camel@intel.com> <22596E35-F5D1-4935-86AB-B510DCA0FABE@amacapital.net> <20181106231730.GR5150@brightrain.aerifal.cx> <20181106232616.GA11101@linux.intel.com> Content-Type: text/plain; charset="us-ascii" In-Reply-To: <20181106232616.GA11101@linux.intel.com> Sender: Rich Felker Return-Path: dalias@aerifal.cx MIME-Version: 1.0 List-ID: On Tue, Nov 06, 2018 at 03:26:16PM -0800, Sean Christopherson wrote: > On Tue, Nov 06, 2018 at 06:17:30PM -0500, Rich Felker wrote: > > On Tue, Nov 06, 2018 at 11:02:11AM -0800, Andy Lutomirski wrote: > > > On Tue, Nov 6, 2018 at 10:41 AM Dave Hansen wrote: > > > > > > > > On 11/6/18 10:20 AM, Andy Lutomirski wrote: > > > > > I almost feel like the right solution is to call into SGX on its own > > > > > private stack or maybe even its own private address space. > > > > > > > > Yeah, I had the same gut feeling. Couldn't the debugger even treat the > > > > enclave like its own "thread" with its own stack and its own set of > > > > registers and context? That seems like a much more workable model than > > > > trying to weave it together with the EENTER context. > > > > > > So maybe the API should be, roughly > > > > > > sgx_exit_reason_t sgx_enter_enclave(pointer_to_enclave, struct > > > host_state *state); > > > sgx_exit_reason_t sgx_resume_enclave(same args); > > > > > > where host_state is something like: > > > > > > struct host_state { > > > unsigned long bp, sp, ax, bx, cx, dx, si, di; > > > }; > > > > > > and the values in host_state explicitly have nothing to do with the > > > actual host registers. So, if you want to use the outcall mechanism, > > > you'd allocate some memory, point sp to that memory, call > > > sgx_enter_enclave(), and then read that memory to do the outcall. > > > > > > Actually implementing this would be distinctly nontrivial, and would > > > almost certainly need some degree of kernel help to avoid an explosion > > > when a signal gets delivered while we have host_state.sp loaded into > > > the actual SP register. Maybe rseq could help with this? > > > > > > The ISA here is IMO not well thought through. > > > > Maybe I'm mistaken about some fundamentals here, but my understanding > > of SGX is that the whole point is that the host application and the > > code running in the enclave are mutually adversarial towards one > > another. Do any or all of the proposed protocols here account for this > > and fully protect the host application from malicious code in the > > enclave? It seems that having control over the register file on exit > > from the enclave is fundamentally problematic but I assume there must > > be some way I'm missing that this is fixed up. > > SGX provides protections for the enclave but not the other way around. > The kernel has all of its normal non-SGX protections in place, but the > enclave can certainly wreak havoc on its userspace process. The basic > design idea is that the enclave is a specialized .so that gets extra > security protections but is still effectively part of the overall > application, e.g. it has full access to its host userspace process' > virtual memory. In that case it seems like the only way to use SGX that's not a gaping security hole is to run the SGX enclave in its own fully-seccomp (or equivalent) process, with no host application in the same address space. Since the host application can't see the contents of the enclave to make any determination of whether it's safe to run, running it in the same address space only makes sense if the cpu provides protection against unwanted accesses to the host's memory from the enclave -- and according to you, it doesn't. Rich From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rich Felker Subject: Re: RFC: userspace exception fixups Date: Wed, 7 Nov 2018 16:27:58 -0500 Message-ID: <20181107212758.GU5150@brightrain.aerifal.cx> References: <1541518670.7839.31.camel@intel.com> <1541524750.7839.51.camel@intel.com> <22596E35-F5D1-4935-86AB-B510DCA0FABE@amacapital.net> <20181106231730.GR5150@brightrain.aerifal.cx> <20181106232616.GA11101@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20181106232616.GA11101@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org To: Sean Christopherson Cc: Andy Lutomirski , Dave Hansen , Jann Horn , Linus Torvalds , Dave Hansen , Jethro Beekman , Jarkko Sakkinen , Florian Weimer , Linux API , X86 ML , linux-arch , LKML , Peter Zijlstra , nhorman@redhat.com, npmccallum@redhat.com, "Ayoun, Serge" , shay.katz-zamir@intel.com, linux-sgx@vger.kernel.org, Andy Shevchenko , Thomas Gleixner , Ingo Molnar , Borislav List-Id: linux-api@vger.kernel.org On Tue, Nov 06, 2018 at 03:26:16PM -0800, Sean Christopherson wrote: > On Tue, Nov 06, 2018 at 06:17:30PM -0500, Rich Felker wrote: > > On Tue, Nov 06, 2018 at 11:02:11AM -0800, Andy Lutomirski wrote: > > > On Tue, Nov 6, 2018 at 10:41 AM Dave Hansen wrote: > > > > > > > > On 11/6/18 10:20 AM, Andy Lutomirski wrote: > > > > > I almost feel like the right solution is to call into SGX on its own > > > > > private stack or maybe even its own private address space. > > > > > > > > Yeah, I had the same gut feeling. Couldn't the debugger even treat the > > > > enclave like its own "thread" with its own stack and its own set of > > > > registers and context? That seems like a much more workable model than > > > > trying to weave it together with the EENTER context. > > > > > > So maybe the API should be, roughly > > > > > > sgx_exit_reason_t sgx_enter_enclave(pointer_to_enclave, struct > > > host_state *state); > > > sgx_exit_reason_t sgx_resume_enclave(same args); > > > > > > where host_state is something like: > > > > > > struct host_state { > > > unsigned long bp, sp, ax, bx, cx, dx, si, di; > > > }; > > > > > > and the values in host_state explicitly have nothing to do with the > > > actual host registers. So, if you want to use the outcall mechanism, > > > you'd allocate some memory, point sp to that memory, call > > > sgx_enter_enclave(), and then read that memory to do the outcall. > > > > > > Actually implementing this would be distinctly nontrivial, and would > > > almost certainly need some degree of kernel help to avoid an explosion > > > when a signal gets delivered while we have host_state.sp loaded into > > > the actual SP register. Maybe rseq could help with this? > > > > > > The ISA here is IMO not well thought through. > > > > Maybe I'm mistaken about some fundamentals here, but my understanding > > of SGX is that the whole point is that the host application and the > > code running in the enclave are mutually adversarial towards one > > another. Do any or all of the proposed protocols here account for this > > and fully protect the host application from malicious code in the > > enclave? It seems that having control over the register file on exit > > from the enclave is fundamentally problematic but I assume there must > > be some way I'm missing that this is fixed up. > > SGX provides protections for the enclave but not the other way around. > The kernel has all of its normal non-SGX protections in place, but the > enclave can certainly wreak havoc on its userspace process. The basic > design idea is that the enclave is a specialized .so that gets extra > security protections but is still effectively part of the overall > application, e.g. it has full access to its host userspace process' > virtual memory. In that case it seems like the only way to use SGX that's not a gaping security hole is to run the SGX enclave in its own fully-seccomp (or equivalent) process, with no host application in the same address space. Since the host application can't see the contents of the enclave to make any determination of whether it's safe to run, running it in the same address space only makes sense if the cpu provides protection against unwanted accesses to the host's memory from the enclave -- and according to you, it doesn't. Rich