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=-7.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, 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 E820FC04AAF for ; Thu, 16 May 2019 22:45:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C3F2220881 for ; Thu, 16 May 2019 22:45:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728523AbfEPWpw (ORCPT ); Thu, 16 May 2019 18:45:52 -0400 Received: from mga14.intel.com ([192.55.52.115]:20424 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726732AbfEPWpw (ORCPT ); Thu, 16 May 2019 18:45:52 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2019 15:45:51 -0700 X-ExtLoop1: 1 Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.36]) by fmsmga005.fm.intel.com with ESMTP; 16 May 2019 15:45:50 -0700 Date: Thu, 16 May 2019 15:45:50 -0700 From: Sean Christopherson To: Andy Lutomirski Cc: Jarkko Sakkinen , James Morris , "Serge E. Hallyn" , LSM List , Paul Moore , Stephen Smalley , Eric Paris , selinux@vger.kernel.org, Jethro Beekman , "Xing, Cedric" , "Hansen, Dave" , Thomas Gleixner , "Dr. Greg" , Linus Torvalds , LKML , X86 ML , "linux-sgx@vger.kernel.org" , Andrew Morton , "nhorman@redhat.com" , "npmccallum@redhat.com" , "Ayoun, Serge" , "Katz-zamir, Shay" , "Huang, Haitao" , Andy Shevchenko , "Svahn, Kai" , Borislav Petkov , Josh Triplett , "Huang, Kai" , David Rientjes Subject: Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support) Message-ID: <20190516224550.GC11204@linux.intel.com> References: <20190513102926.GD8743@linux.intel.com> <20190514104323.GA7591@linux.intel.com> <20190514204527.GC1977@linux.intel.com> <20190515013031.GF1977@linux.intel.com> <20190516051622.GC6388@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-sgx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On Thu, May 16, 2019 at 02:02:58PM -0700, Andy Lutomirski wrote: > > On May 15, 2019, at 10:16 PM, Jarkko Sakkinen wrote: > > There is a problem here though. Usually the enclave itself is just a > > loader that then loads the application from outside source and creates > > the executable pages from the content. > > > > A great example of this is Graphene that bootstraps unmodified Linux > > applications to an enclave: > > > > https://github.com/oscarlab/graphene > > > > ISTM you should need EXECMEM or similar to run Graphene, then. Agreed, Graphene is effectively running arbitrary enclave code. I'm guessing there is nothing that prevents extending/reworking Graphene to allow generating the enclave ahead of time so as to avoid populating the guts of the enclave at runtime, i.e. it's likely possible to run an unmodified application in an enclave without EXECMEM if that's something Graphene or its users really care about.