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=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 CE1DCC28CC0 for ; Thu, 30 May 2019 22:24:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ACB5B22CE5 for ; Thu, 30 May 2019 22:24:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726558AbfE3WYZ (ORCPT ); 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-sgx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sgx@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).