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 B4897C43463 for ; Fri, 18 Sep 2020 23:53:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4166120885 for ; Fri, 18 Sep 2020 23:53:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4166120885 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 776266B005C; Fri, 18 Sep 2020 19:53:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74BC26B005D; Fri, 18 Sep 2020 19:53:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6621F6B0062; Fri, 18 Sep 2020 19:53:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0165.hostedemail.com [216.40.44.165]) by kanga.kvack.org (Postfix) with ESMTP id 4FE9B6B005C for ; Fri, 18 Sep 2020 19:53:50 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 14035181AEF1D for ; Fri, 18 Sep 2020 23:53:50 +0000 (UTC) X-FDA: 77277837420.06.death15_1f0c08e2712f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id D674E101188E0 for ; Fri, 18 Sep 2020 23:53:49 +0000 (UTC) X-HE-Tag: death15_1f0c08e2712f X-Filterd-Recvd-Size: 5855 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Fri, 18 Sep 2020 23:53:48 +0000 (UTC) IronPort-SDR: /szW3t9OmvbhwW+CL7EaNkI4MKSRINqkms+d5FMIBuC5mo/yVaKk9Jwyl50oDHuGz/F0vHVeYf uMBcsEI0fQJw== X-IronPort-AV: E=McAfee;i="6000,8403,9748"; a="224213158" X-IronPort-AV: E=Sophos;i="5.77,276,1596524400"; d="scan'208";a="224213158" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Sep 2020 16:53:41 -0700 IronPort-SDR: 7Tx3tHHwo1WoVwkybdZU7HNvtlLMmqX3VW0acb1K3sujhz8PdF+fzQtAi4QgCRrc9FtFlGDduE oOSShv2q69YQ== X-IronPort-AV: E=Sophos;i="5.77,276,1596524400"; d="scan'208";a="381080557" Received: from sjchrist-ice.jf.intel.com (HELO sjchrist-ice) ([10.54.31.34]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Sep 2020 16:53:38 -0700 Date: Fri, 18 Sep 2020 16:53:37 -0700 From: Sean Christopherson To: Andy Lutomirski Cc: Jarkko Sakkinen , 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: <20200918235337.GA21189@sjchrist-ice> References: <20200915112842.897265-1-jarkko.sakkinen@linux.intel.com> <20200915112842.897265-11-jarkko.sakkinen@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) 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 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. 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. Future LSM policies have a similar need due to vm_file always pointing at /dev/sgx/enclave, e.g. policies couldn't be attached to a specific enclave. ->mprotect() again allows enforcing permissions at map time that were checked at enclave build time, e.g. via an LSM hook. Deferring ->mprotect() until LSM support is added (if it ever is) would be problematic due to SGX2. With SGX2, userspace can extend permissions of an enclave page (for the CPU's EPC Map entry, not the kernel's page tables) without bouncing through the kernel. Without ->mprotect () enforcement. userspace could do EADD(RW) -> mprotect(RWX) -> EMODPE(X) to gain W+X. We want to disallow such a flow now, i.e. force userspace to do EADD(RW,X), so that the hypothetical LSM hook would have all information at EADD(), i.e. would be aware of the EXEC permission, without creating divergent behavior based on whether or not an LSM is active.