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,USER_AGENT_MUTT autolearn=unavailable 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 B56E4C04E53 for ; Wed, 15 May 2019 21:39:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8F4062082E for ; Wed, 15 May 2019 21:39:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726822AbfEOVjA (ORCPT ); Wed, 15 May 2019 17:39:00 -0400 Received: from mga07.intel.com ([134.134.136.100]:48585 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726441AbfEOVjA (ORCPT ); Wed, 15 May 2019 17:39:00 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2019 14:38:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,474,1549958400"; d="scan'208";a="172102692" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.36]) by fmsmga002.fm.intel.com with ESMTP; 15 May 2019 14:38:58 -0700 Date: Wed, 15 May 2019 14:38:58 -0700 From: Sean Christopherson To: Andy Lutomirski Cc: James Morris , "Serge E. Hallyn" , LSM List , Paul Moore , Stephen Smalley , Eric Paris , selinux@vger.kernel.org, Jarkko Sakkinen , 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: <20190515213858.GG5875@linux.intel.com> References: <960B34DE67B9E140824F1DCDEC400C0F4E886094@ORSMSX116.amr.corp.intel.com> <6da269d8-7ebb-4177-b6a7-50cc5b435cf4@fortanix.com> <20190513102926.GD8743@linux.intel.com> <20190514104323.GA7591@linux.intel.com> <20190514204527.GC1977@linux.intel.com> <20190515013031.GF1977@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 Wed, May 15, 2019 at 11:27:04AM -0700, Andy Lutomirski wrote: > 2) Just like any other DSO, there are potential issues with how > enclaves deal with writable vs executable memory. This takes two > forms. First, a task should probably require EXECMEM, EXECMOD, or > similar permission to run an enclave that can modify its own text. > Second, it would be nice if a task that did *not* have EXECMEM, > EXECMOD, or similar could still run the enclave if it had EXECUTE > permission on the file containing the enclave. > > Currently, this all works because DSOs are run by mmapping the file to > create multiple VMAs, some of which are executable, non-writable, and > non-CoWed, and some of which are writable but not executable. With > SGX, there's only really one inode per enclave (the anon_inode that > comes form /dev/sgx/enclave), and it can only be sensibly mapped > MAP_SHARED. I was wrong when I said /dev/sgx/enclave creates and returns an anon inode. I was thinking of the KVM model for creating VMs. SGX creates an enclave when /dev/sgx/enclave is opened and associates the enclave with the newly opened /dev/sgx/enclave fd. Regardless, the fundamental problem remains, mmap() of EPC works on a single inode.