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.2 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 1BA7AC43468 for ; Mon, 21 Sep 2020 16:58:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AC5512223E for ; Mon, 21 Sep 2020 16:58:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC5512223E 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 C6FC490009A; Mon, 21 Sep 2020 12:58:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C44EB90008B; Mon, 21 Sep 2020 12:58:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5BD290009A; Mon, 21 Sep 2020 12:58:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0243.hostedemail.com [216.40.44.243]) by kanga.kvack.org (Postfix) with ESMTP id A287490008B for ; Mon, 21 Sep 2020 12:58:03 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5BAF9180AD802 for ; Mon, 21 Sep 2020 16:58:03 +0000 (UTC) X-FDA: 77287676046.02.bread08_1309aa927146 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id 1609C10137395 for ; Mon, 21 Sep 2020 16:58:03 +0000 (UTC) X-HE-Tag: bread08_1309aa927146 X-Filterd-Recvd-Size: 6455 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 16:58:01 +0000 (UTC) IronPort-SDR: VVlbnFR+ZinNJIQtJufajRIcmAKfBWGmkh+7EphNvaYst+MnnDhfwILwMK1x+VSQnyKaHvXFzi eGmMAQLMCh0Q== X-IronPort-AV: E=McAfee;i="6000,8403,9751"; a="159726409" X-IronPort-AV: E=Sophos;i="5.77,287,1596524400"; d="scan'208";a="159726409" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2020 09:58:00 -0700 IronPort-SDR: PXsps/O62f8wFH4mBRAPPFgpdrRBdDLwYdGh0/OnMboQI2p+CKo9GmnFSImvP3Sy9FmpwatIwq UH8dlvEUrFuA== X-IronPort-AV: E=Sophos;i="5.77,287,1596524400"; d="scan'208";a="341648921" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.160]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2020 09:57:59 -0700 Date: Mon, 21 Sep 2020 09:57:58 -0700 From: Sean Christopherson To: Jarkko Sakkinen 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: <20200921165758.GA24156@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200921124946.GF6038@linux.intel.com> 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 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: > > On Fri, Sep 18, 2020 at 08:09:04AM -0700, Andy Lutomirski wrote: > > > On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen > > > wrote: > > > > > > > > From: Sean Christopherson > > > > > > > > Add vm_ops()->mprotect() for additional constraints for a VMA. > > > > > > > > Intel Software Guard eXtensions (SGX) will use this callback to add two > > > > constraints: > > > > > > > > 1. Verify that the address range does not have holes: each page address > > > > must be filled with an enclave page. > > > > 2. Verify that VMA permissions won't surpass the permissions of any enclave > > > > page within the address range. Enclave cryptographically sealed > > > > permissions for each page address that set the upper limit for possible > > > > VMA permissions. Not respecting this can cause #GP's to be emitted. > > > > Side note, #GP is wrong. EPCM violations are #PFs. Skylake CPUs #GP, but > > that's technically an errata. But this isn't the real motivation, e.g. > > userspace can already trigger #GP/#PF by reading/writing a bad address, SGX > > simply adds another flavor. > > > > > It's been awhile since I looked at this. Can you remind us: is this > > > just preventing userspace from shooting itself in the foot or is this > > > something more important? > > > > Something more important, it's used to prevent userspace from circumventing > > 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. > > The ->mprotect() hook allows SGX to reject mprotect() if userspace is declaring > > permissions beyond what are allowed, e.g. trying to map an enclave page with > > EXEC permissions when the page was added to the enclave without EXEC. > > For my ear this is tautological because if user space would use > differing permissions, it would exactly soot itself in the foot. Not on SGX2 hardware. The kernel can't disable ENCLU[MODPE]. > What really should be documented is to answer why we consider an enclave > mappable, if and only if the conditions are that I described about > sgx_encl_may_map() functioning. > > This is obviously part of the answer [*], i.e. with pharsing LSM hook > requires an enclave to have a state, which is compatible with the mmap > permissions and is fully populated. > > The 2nd part of the answer is the answer to the question: why we want to > feed LSM hooks enclaves exactly in this state. > > What would you answer to that? I would copy-paste the part of the response that was snipped... > [*] https://lore.kernel.org/linux-sgx/20200918232458.GA6175@linux.intel.com/T/#u > > /Jarkko