Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp798385ybi; Fri, 24 May 2019 11:35:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqyzLa+ksXP9wQ+QzAUGvdq6kdK0xmKwyqQ1f/xHlM38j+wA7N37uzt9pysHGCxaBY9PKmBB X-Received: by 2002:a17:902:9305:: with SMTP id bc5mr8687055plb.193.1558722952446; Fri, 24 May 2019 11:35:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558722952; cv=none; d=google.com; s=arc-20160816; b=k9xN3+tXXmJyJmS8d1rqgoR6w1r7chKkIEk5rT2Tkd0+jpuXvGmn5Vm/z1RyBYc5iG DkJXUnGt/JzxJsF+/S9QoEOcIbzKKy2pudeOji5Z//Gl/IZdSJZ1SpGJyCw0+NwZtFO4 NISeOWNpLswXynsSbVMBrxMgxQ5pDHAveIlTps8LIbRC2jo3biBkWedAAllj1yZecNY5 cUTPGSgERYdf0+tjXZl2rQ0fAcE2OBt6/umAsmhdXmE2GCsmq7evucvkNGln1CIhtFf4 V2yKy6KTaie9gcp0xIU0/DQ8rdXNLPnGsFEPksojrzeZkiwAsw6uDZ4j70pHrD8QUXc1 tPyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :dlp-reaction:dlp-version:dlp-product:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=a/aheYJjN200oVCZec9yw01COjOeZ6Ybqt/u/gW8VSk=; b=046OriHgeO93pX5aw/0w/6jrjK85d2qIGkPJc6ufDcRngXHF9FvtEqkLYDHvV2NOO6 E/ugVnVtCl+1n9oYE02l1gFwkoChQ9bpteHPXd5nCqCFcjawVr2V2kvADbS7Zi9S0ocG sg75UySyjdMsgk6AZzY8W0hGIH4WTLHCYDoOoEfnxDgBAKUErmRjn/biIoKHRtAulf7w 8wAntopDt36WAaN/JFqkK5AVglcUyMmrV8Qm2T+qY30V5Cl+PTL4u5ytTbI9c0XEYtt5 MSJiJq0NH+YquGQQGGcmSE552mHE6e7PWmAKbGFwbxIPsaA4MBblcrTwWmfpGWKzoOdk tSPw== 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 t2si5482628pfa.11.2019.05.24.11.35.37; Fri, 24 May 2019 11:35:52 -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 S1732020AbfEXSee convert rfc822-to-8bit (ORCPT + 99 others); Fri, 24 May 2019 14:34:34 -0400 Received: from mga04.intel.com ([192.55.52.120]:27663 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727465AbfEXSed (ORCPT ); Fri, 24 May 2019 14:34:33 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2019 11:34:33 -0700 X-ExtLoop1: 1 Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by orsmga005.jf.intel.com with ESMTP; 24 May 2019 11:34:33 -0700 Received: from orsmsx121.amr.corp.intel.com (10.22.225.226) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 24 May 2019 11:34:33 -0700 Received: from orsmsx116.amr.corp.intel.com ([169.254.7.165]) by ORSMSX121.amr.corp.intel.com ([169.254.10.64]) with mapi id 14.03.0415.000; Fri, 24 May 2019 11:34:32 -0700 From: "Xing, Cedric" To: "Christopherson, Sean J" , "Stephen Smalley" CC: Andy Lutomirski , 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) Thread-Topic: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support) Thread-Index: AQHVC0vUmIXibKT8TUm/EUnHn2XAfqZu5q2AgAAGWoCABXOKgIABz2SAgAAI9ACAAWgPAIAAAJWAgAAJhACAAByGAIAAdoKAgABA+ICAAIOmAIAAQKcAgAAWeICAAIbLAIAAGyYA///WAeCAARtHgIAAIeCAgAADbAD//5AmcA== Date: Fri, 24 May 2019 18:34:32 +0000 Message-ID: <960B34DE67B9E140824F1DCDEC400C0F654E8E1D@ORSMSX116.amr.corp.intel.com> References: <20190523023517.GA31950@linux.intel.com> <20190523102628.GC10955@linux.intel.com> <20190523141752.GA12078@linux.intel.com> <20190523234044.GC12078@linux.intel.com> <960B34DE67B9E140824F1DCDEC400C0F654E8956@ORSMSX116.amr.corp.intel.com> <20190524174243.GA365@linux.intel.com> <20190524175458.GB365@linux.intel.com> In-Reply-To: <20190524175458.GB365@linux.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjM1YjY3NGMtZmM1Mi00ZWM3LTg2MWEtZjQ4MjdjMTI2MTg4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoieEgxQ1NRZkl6MlIyMEN5YzZBT01zQTA2dngxUDA1ajFGcm81R2VLeExWSHZEYnVLRjM3bFErRUtNN0FsbDlMSCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > From: linux-sgx-owner@vger.kernel.org [mailto:linux-sgx- > owner@vger.kernel.org] On Behalf Of Sean Christopherson > Sent: Friday, May 24, 2019 10:55 AM > > On Fri, May 24, 2019 at 10:42:43AM -0700, Sean Christopherson wrote: > > Hmm, I've been thinking more about pulling permissions from the source > > page. Conceptually I'm not sure we need to meet the same requirements > as > > non-enclave DSOs while the enclave is being built, i.e. do we really > need > > to force userspace to fully map the enclave in normal memory? > > > > Consider the Graphene scenario where it's building an enclave on the > fly. > > Pulling permissions from the source VMAs means Graphene has to map the > > code pages of the enclave with X. This means Graphene will need > EXEDMOD > > (or EXECMEM if Graphene isn't careful). In a non-SGX scenario this > makes > > perfect sense since there is no way to verify the end result of RW->RX. > > > > But for SGX, assuming enclaves are whitelisted by their sigstruct > (checked > > at EINIT) and because page permissions affect sigstruct.MRENCLAVE, it > *is* > > possible to verify the resulting RX contents. E.g. for the purposes > of > > LSMs, can't we use the .sigstruct file as a proxy for the enclave and > > require FILE__EXECUTE on the .sigstruct inode to map/run the enclave? > > > > Stephen, is my logic sound? > > > > > > If so... > > > > - Require FILE__READ+FILE__EXECUTE on .sigstruct to mmap() the > enclave. > > > > - Prevent userspace from mapping the enclave with permissions beyond > the > > original permissions of the enclave. This can be done by > populating > > VM_MAY{READ,WRITE,EXEC} from the SECINFO (same basic concept as > Andy's > > proposals). E.g. pre-EINIT, mmap() and mprotect() can only > succeed > > with PROT_NONE. > > > > - Require FILE__{READ,WRITE,EXECUTE} on /dev/sgx/enclave for > simplicity, > > or provide an alternate SGX_IOC_MPROTECT if we want to sidestep > the > > FILE__WRITE requirement. > > One more thought. EADD (and the equivalent SGX2 flow) could do > security_mmap_file() with a NULL file on the SECINFO permissions, which > would trigger PROCESS_EXECMEM if an enclave attempts to map a page RWX. If "initial permissions" for enclaves are less restrictive than shared objects, then it'd become a backdoor for circumventing LSM when enclave whitelisting is *not* in place. For example, an adversary may load a page, which would otherwise never be executable, as an executable page in EPC. In the case a RWX page is needed, the calling process has to have a RWX page serving as the source for EADD so PROCESS__EXECMEM will have been checked. For SGX2, changing an EPC page to RWX is subject to FILE__EXECMEM on /dev/sgx/enclave, which I see as a security benefit because it only affects the enclave but not the whole process hosting it. > > > No changes are required to LSMs, SGX1 has a single LSM touchpoint in > its > > mmap(), and I *think* the only required userspace change is to mmap() > > PROT_NONE when allocating the enclave's virtual address range. I'm not sure I understand the motivation behind this proposal to decouple initial EPC permissions from source pages. I don't think it a big deal to fully mmap() enclave files, which have to be parsed by user mode anyway to determine various things including but not limited to the size of heap(s), size and number of TCSs/stacks/TLS areas, and the overall enclave size. So with PHDRs parsed, it's trivial to mmap() each segment with permissions from its PHDR. > > > > As for Graphene, it doesn't need extra permissions to run its enclaves, > > it just needs a way to install .sigstruct, which is a generic > permissions > > problem and not SGX specific. > > > > > > For SGX2 maybe: > > > > - No additional requirements to map an EAUG'd page as RW page. Not > > aligned with standard MAP_SHARED behavior, but we really don't > want > > to require FILE__WRITE, and thus allow writes to .sigstruct. > > > > - Require FILE__EXECMOD on the .sigstruct to map previously writable > > page as executable (which indirectly includes all EAUG'd pages). > > Wiring this up will be a little funky, but we again we don't want > > to require FILE__WRITE on .sigstruct. > > I'm lost. Why is EAUG tied to permissions on .sigstruct? -Cedric