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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 3078DC4363C for ; Mon, 21 Sep 2020 21:07:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A26E120B1F for ; Mon, 21 Sep 2020 21:07:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A26E120B1F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B8EFA6B00DD; Mon, 21 Sep 2020 17:07:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B17E66B00DE; Mon, 21 Sep 2020 17:07:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 992AC6B00DF; Mon, 21 Sep 2020 17:07:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0024.hostedemail.com [216.40.44.24]) by kanga.kvack.org (Postfix) with ESMTP id 7D4926B00DD for ; Mon, 21 Sep 2020 17:07:48 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 376A0349B for ; Mon, 21 Sep 2020 21:07:48 +0000 (UTC) X-FDA: 77288305416.12.blood13_4913a0827148 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 05EFC1800F741 for ; Mon, 21 Sep 2020 21:07:48 +0000 (UTC) X-HE-Tag: blood13_4913a0827148 X-Filterd-Recvd-Size: 5280 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 21:07:47 +0000 (UTC) IronPort-SDR: ke+kNgvCy/LUz58kY1Qan3DK9oFG5VILQCIu/kr/2ddPpvgdAakhT7KC5xdV3bhrKazLsBcmaX T/nE2R7uYGGw== X-IronPort-AV: E=McAfee;i="6000,8403,9751"; a="161402603" X-IronPort-AV: E=Sophos;i="5.77,288,1596524400"; d="scan'208";a="161402603" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2020 14:07:45 -0700 IronPort-SDR: wNwnTNAM5ERduoiu28YwFRd0UBOnm3SIUU5AD4goCxAsx3sByaFOizwkhBI1qP/CQGQq0rFEag 1T4MmGFQFDJA== X-IronPort-AV: E=Sophos;i="5.77,288,1596524400"; d="scan'208";a="485667937" Received: from kofels-mobl.ger.corp.intel.com (HELO localhost) ([10.249.45.179]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2020 14:07:38 -0700 Date: Tue, 22 Sep 2020 00:07:36 +0300 From: Jarkko Sakkinen To: Sean Christopherson Cc: 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, Dave Hansen , "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: <20200921210736.GB58176@linux.intel.com> References: <20200915112842.897265-1-jarkko.sakkinen@linux.intel.com> <20200915112842.897265-11-jarkko.sakkinen@linux.intel.com> <20200918235337.GA21189@sjchrist-ice> <20200921124946.GF6038@linux.intel.com> <20200921165758.GA24156@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200921165758.GA24156@linux.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo 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 Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote: > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote: > > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote: > > > a noexec filesystem by loading code into an enclave, and to give the kernel the > > > option of adding enclave specific LSM policies in the future. > > > > > > The source file (if one exists) for the enclave is long gone when the enclave > > > is actually mmap()'d and mprotect()'d. To enforce noexec, the requested > > > permissions for a given page are snapshotted when the page is added to the > > > enclave, i.e. when the enclave is built. Enclave pages that will be executable > > > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a > > > noexec file system. > > > > noexec check is done in __sgx_encl_add_page(), not in this callback. > > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the > > addresses, checks that permissions are not surpassed and there are > > no holes. > > Yes, that's what I said. sgx_encl_add_page() will remove such page. The callback does not interact with this process as such pages never get to the enclave. > I would copy-paste the part of the response that was snipped... I do agree with the main conclusions but it contains also things that I do not see relating that much, like noexec partitions. It goes too far in detail what will LSM's end up doing. I absolutely do not want to forecast too far how LSM hooks would work. Since we do not have ioctl's for EMODPE and such, I see EMODPE as the only reason for doing this right now. Otherwise, we are in trouble with any possible LSM callbacks. For any sort of access control decision, things decided must stick. I would add something like this to the commit message largely based on your text: "SGX stores the permissions for each page when they are first added, and will implement this callback to check that mmap() or mprotect() does not surpass these permissions in the requested address range. This is done to prevent using EMODPE upgrading permissions of a page after mmap() or mprotect() has been done, which would prevent any sort of LSM callbacks to be implemented later on because the access control decision could deprecate." /Jarkko