Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1311999ybi; Thu, 30 May 2019 15:25:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqxtaxPL1RGwmUGt3j6xXG+aoFjS0qTNXuNKXHXspbemRnZSkJBPMlkZuE5vPcv2gIpyWPGb X-Received: by 2002:a63:d949:: with SMTP id e9mr5660740pgj.437.1559255154005; Thu, 30 May 2019 15:25:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559255153; cv=none; d=google.com; s=arc-20160816; b=ze1g/afGEsq/YorkeJGj6sy+nFg8Vp2ZNxQ6osCUXWWwmpYcr1Lz5A9uNj8nBuS1s+ dfJotVbkk1SNpcv294i1EI+NKatbASx97WbMI1yivgQqZMqUnD00fcNXrC0JWnJEp8Ae s0YA9WuNWzV7z+1wptm6kKpzzcTjdLekOboOzw8dxPheRflU7gp0eye/VUBPj4b5oiX5 qO6jpYt8Z8zU/RYQ8VP7GN2d0TCnwwsK81imZ5cMv2Qdv0eUsxooniRVemTMjyutB9JN EhiLxcpNLGqhmPFiur0oxCzbWEoH765siqEEHbqsvjPgKmrR8MOcSQusmnlCK/9SHsBk 2IpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=hBA6lVFSdQgWWMdIO+o2NSQWLergfSqJ3tBxvI4n92I=; b=u7IU7+HLdRdtNyAErkOJ0kY59inO1+B7xGd9iWsBrBvEHNpsXq7rtd9ZT/6LJr4ZAc sUh96am9zT+0dIfUM4CgCHSPCHOHO5x8yoROrNbUXa9JxKbfb9ZmK1LMtzmNN7A/Ki/5 eWt+J0IHLpzDM8/rjHx90wFJOR1MBCOrYZAfSWx40X02eYW/kyxiE7kaDWJAAbhPkAty uI7oW867EH1kmwTm2hoy5kJaR81qrfC/rz+v1ybLsdfZjesMSuCkIB1LL8X2xoB+Uppc BO0CNYBzL0S+nJX2l+nmVoXHexM2m84BWYPPgbP8zIY4GQWjwiw/L2UP0TzAGoZEOpL7 qOUA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 126si4114398pgc.2.2019.05.30.15.25.38; Thu, 30 May 2019 15:25:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726666AbfE3WYZ (ORCPT + 99 others); Thu, 30 May 2019 18:24:25 -0400 Received: from mga05.intel.com ([192.55.52.43]:23038 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726045AbfE3WYZ (ORCPT ); Thu, 30 May 2019 18:24:25 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 May 2019 15:24:24 -0700 X-ExtLoop1: 1 Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.36]) by FMSMGA003.fm.intel.com with ESMTP; 30 May 2019 15:24:23 -0700 Date: Thu, 30 May 2019 15:24:23 -0700 From: Sean Christopherson To: "Xing, Cedric" Cc: Andy Lutomirski , Stephen Smalley , William Roberts , Jarkko Sakkinen , James Morris , "Serge E. Hallyn" , LSM List , Paul Moore , Eric Paris , "selinux@vger.kernel.org" , Jethro Beekman , "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: <20190530222423.GD27551@linux.intel.com> References: <20190528202407.GB13158@linux.intel.com> <285f279f-b500-27f0-ab42-fb1dbcc5ab18@tycho.nsa.gov> <960B34DE67B9E140824F1DCDEC400C0F654EB487@ORSMSX116.amr.corp.intel.com> <678a37af-797d-7bd5-a406-32548a270e3d@tycho.nsa.gov> <20190530180110.GB23930@linux.intel.com> <960B34DE67B9E140824F1DCDEC400C0F654EB8BA@ORSMSX116.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <960B34DE67B9E140824F1DCDEC400C0F654EB8BA@ORSMSX116.amr.corp.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 30, 2019 at 02:48:43PM -0700, Xing, Cedric wrote: > So I think the same rationale applies to enclaves. Your original idea of > MAXPERM is the policy set forth by system admin and shall *never* change at > runtime. If an enclave is dynamically linked and needs to bring in code pages > at runtime, the admin needs to enable it by setting, say ENCLAVE__EXECMOD, in > the sigstruct file. Then all EAUG'ed pages will receive RWX as MAXPERM. The > process would then mprotect() selective pages to be RX but which exact set of > pages doesn't concern LSM usually. Because passing RWX means the enclave "requires" EXECMOD even if it never actually does a RW->RX transition. It's not broken per se, but at the very least it's decidedly odd. Dynamically detecting the EXECMOD case is not difficult and has the advantage of simplifying userspace loaders, e.g. all EAUG pages are tagged ALLOW_WRITE and the kernel takes care of the rest. I *think* auditing/learning is also messed up with a MAXPERMS approach, as mprotect() would fail (due to MAXPERMS clearing MAY_{READ,WRITE,EXEC}) before it calls security_file_mprotect(). Hooking mprotect() is the obvious workaround, but then it's looking a lot like the new proposals. In other words, the new proposals are rooted in the MAXPERMS concept, e.g. MAXPERM is effectively "I want EXECMOD", which gets distilled down to ALLOW_WRITE (or ALLOW_EXEC in Andy's proposal).