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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 C72BEC4363D for ; Thu, 24 Sep 2020 20:02:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5379D2344C for ; Thu, 24 Sep 2020 20:02:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5379D2344C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 608856B005C; Thu, 24 Sep 2020 16:02:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BA688E0001; Thu, 24 Sep 2020 16:02:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CFC96B0062; Thu, 24 Sep 2020 16:02:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0085.hostedemail.com [216.40.44.85]) by kanga.kvack.org (Postfix) with ESMTP id 38BB66B005C for ; Thu, 24 Sep 2020 16:02:10 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D71E2824999B for ; Thu, 24 Sep 2020 20:02:09 +0000 (UTC) X-FDA: 77299026378.22.bone27_300d77e27161 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 952FB18038E68 for ; Thu, 24 Sep 2020 20:02:09 +0000 (UTC) X-HE-Tag: bone27_300d77e27161 X-Filterd-Recvd-Size: 5459 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Thu, 24 Sep 2020 20:02:08 +0000 (UTC) IronPort-SDR: XCqOAOxxQNUc6CwewVmHo1oZFW+sScGANfgOlqTCd/kgf1ZGiOmmO19WSydpyVvb69Dvz6Lb+q HdXOvDD09+og== X-IronPort-AV: E=McAfee;i="6000,8403,9754"; a="246136006" X-IronPort-AV: E=Sophos;i="5.77,299,1596524400"; d="scan'208";a="246136006" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Sep 2020 13:01:58 -0700 IronPort-SDR: xPsthE/BSH1LRuZED06CxuzJbuNC+7hL54fu/LRloHKfq0y4iE/8EwOu9ok9QwRfaer0dI4PlI LDTge9KmZvIQ== X-IronPort-AV: E=Sophos;i="5.77,299,1596524400"; d="scan'208";a="511757770" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.160]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Sep 2020 13:01:57 -0700 Date: Thu, 24 Sep 2020 13:01:56 -0700 From: Sean Christopherson To: Dave Hansen Cc: Haitao Huang , Jarkko Sakkinen , Andy Lutomirski , X86 ML , linux-sgx@vger.kernel.org, LKML , Linux-MM , Andrew Morton , Matthew Wilcox , Jethro Beekman , Darren Kenny , Andy Shevchenko , asapek@google.com, Borislav Petkov , "Xing, Cedric" , chenalexchen@google.com, Conrad Parker , cyhanish@google.com, "Huang, Haitao" , Josh Triplett , "Huang, Kai" , "Svahn, Kai" , Keith Moyer , Christian Ludloff , Neil Horman , Nathaniel McCallum , Patrick Uiterwijk , David Rientjes , Thomas Gleixner , yaozhangx@google.com Subject: Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect() Message-ID: <20200924200156.GA19127@linux.intel.com> References: <20200921165758.GA24156@linux.intel.com> <20200921210736.GB58176@linux.intel.com> <20200921211849.GA25403@linux.intel.com> <20200922052957.GA97272@linux.intel.com> <20200922053515.GA97687@linux.intel.com> <20200922164301.GB30874@linux.intel.com> <20200923135056.GD5160@linux.intel.com> <20200924192853.GA18826@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) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Sep 24, 2020 at 12:39:24PM -0700, Dave Hansen wrote: > On 9/24/20 12:28 PM, Sean Christopherson wrote: > > On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote: > >> On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen > >> wrote: > >>> I'll categorically deny noexec in the next patch set version. > >>> > >>> /Jarkko > >> There are use cases supported currently in which enclave binary is received > >> via IPC/RPC and held in buffers before EADD. Denying noexec altogether would > >> break those, right? > > No. noexec only applies to file-backed VMAs, what you're describing is loading > > an enclave from an anon VMA, which will still have VM_MAYEXEC. > > Maybe I'm just stupid, but I still don't get the scenario that's being > thwarted or why it is valuable. The SDM is worthless on what EMODPE > does or what its restrictions are. > > In pseudo-C, it's something logically like this for the "nice" case: > > ptr = mmap("/some/executable", PROT_EXEC); > ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size); > mmap(sgx_fd); > EENTER; > > And we're trying to thwart: > > ptr = mmap("/mnt/noexec/file", PROT_READ); > ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size); > mmap(sgx_fd); > EENTER; > > because that loads data into the enclave which is executable but which > was not executable normally. But, we're allowing this from anonymous > memory, so this would seem to work: > > ptr = mmap("/mnt/noexec/file", PROT_READ); > buffer = malloc(PAGE_SIZE); > memcpy(buffer, ptr, PAGE_SIZE); > // need mprotect(buf, PROT_EXEC)??? > ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size); > mmap(sgx_fd); > EENTER; > > and give the same result. What am I missing? The last example, where the enclave is copied to a buffer, is out of scope for noexec. But, it is in scope for LSMs, e.g. for this last example, we could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an SGX specific equivalent). The ->mprotect() hook gives us direct line of sight to such LSM upcalls, e.g. I have fully working code that implements the LSM integration. LSM support isn't in this series because the only thing everyone could agree on in terms of an LSM implementation is that it wasn't needed for initial upstreaming :-)