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_HELO_NONE,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 969C4C07542 for ; Mon, 27 May 2019 13:34:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7A47320883 for ; Mon, 27 May 2019 13:34:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726526AbfE0Net (ORCPT ); Mon, 27 May 2019 09:34:49 -0400 Received: from mga02.intel.com ([134.134.136.20]:30696 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726264AbfE0Net (ORCPT ); Mon, 27 May 2019 09:34:49 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 May 2019 06:34:48 -0700 X-ExtLoop1: 1 Received: from pgomulkx-mobl.ger.corp.intel.com (HELO localhost) ([10.251.94.230]) by orsmga001.jf.intel.com with ESMTP; 27 May 2019 06:34:37 -0700 Date: Mon, 27 May 2019 16:34:31 +0300 From: Jarkko Sakkinen To: Sean Christopherson Cc: Andy Lutomirski , Stephen Smalley , James Morris , "Serge E. Hallyn" , LSM List , Paul Moore , 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: <20190527133418.GA9732@linux.intel.com> References: <20190521151836.GA4843@linux.intel.com> <20190521155140.GE22089@linux.intel.com> <20190522132022.GC31176@linux.intel.com> <20190522132227.GD31176@linux.intel.com> <0e183cce-c4b4-0e10-dbb6-bd81bea58b66@tycho.nsa.gov> <20190522153836.GA24833@linux.intel.com> <20190523023517.GA31950@linux.intel.com> <20190523102628.GC10955@linux.intel.com> <20190523141752.GA12078@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190523141752.GA12078@linux.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org On Thu, May 23, 2019 at 07:17:52AM -0700, Sean Christopherson wrote: > 1. Do nothing. Userspace would essentially be required to mmap() the > enclave after EINIT, which is ugly but not breaking since userspace > could mmap() the enclave with a placeholder VMA prior to building > the enclave, and then a series of mmap() to establish its "real" > mapping. What it'd break to return error if mmap() is done before EINIT? > 2. Propagate the permissions from EADD to the VMAs of the current mm > if the entire EADD range is mapped and the mapping is PROT_NONE. Right now you can do multiple mmap's. If the mmap's must be done after EINIT, the driver could check that permissions match the permissions in that range. This leaves open how to deal with mprotect() but if the process does not have FILE__WRITE I guess you cannot do much. > 3. Propagate the permissions from EADD to the VMAs of all mm structs > that have mapped some piece of the enclave, following the matching > rules from #2. For me it looks that allowing mmap's only after EINIT would result the least confusing implemntation. /Jarkko