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, URIBL_BLOCKED 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 2E770C43463 for ; Mon, 21 Sep 2020 12:50:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AC52520874 for ; Mon, 21 Sep 2020 12:50:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC52520874 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 079E9900055; Mon, 21 Sep 2020 08:50:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 001F56B00C4; Mon, 21 Sep 2020 08:49:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBDA0900055; Mon, 21 Sep 2020 08:49:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0169.hostedemail.com [216.40.44.169]) by kanga.kvack.org (Postfix) with ESMTP id BF4D76B00C3 for ; Mon, 21 Sep 2020 08:49:59 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7EABC362B for ; Mon, 21 Sep 2020 12:49:59 +0000 (UTC) X-FDA: 77287050918.30.scarf87_321604827145 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 5BD3E180B3C83 for ; Mon, 21 Sep 2020 12:49:59 +0000 (UTC) X-HE-Tag: scarf87_321604827145 X-Filterd-Recvd-Size: 6095 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 12:49:58 +0000 (UTC) IronPort-SDR: rPD02Xl5V7eqv5jL6H4gdfrTs9RSHG6McynnA3pOQoOeuNPSyBnyv5aF3+6U1VyNWg3JrX3Io6 dhelk3gaWb6Q== X-IronPort-AV: E=McAfee;i="6000,8403,9750"; a="224513980" X-IronPort-AV: E=Sophos;i="5.77,286,1596524400"; d="scan'208";a="224513980" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2020 05:49:56 -0700 IronPort-SDR: PoA3sms4lExE6ozgbk85Ab4msscys/H2/K2us+7Jz20AKWsgnqupEP9kzK1NSh5A8VNWcV6P3S HdJgEzaMIvLQ== X-IronPort-AV: E=Sophos;i="5.77,286,1596524400"; d="scan'208";a="454028766" Received: from clairemo-mobl.ger.corp.intel.com (HELO localhost) ([10.252.43.50]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2020 05:49:49 -0700 Date: Mon, 21 Sep 2020 15:49:46 +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: <20200921124946.GF6038@linux.intel.com> References: <20200915112842.897265-1-jarkko.sakkinen@linux.intel.com> <20200915112842.897265-11-jarkko.sakkinen@linux.intel.com> <20200918235337.GA21189@sjchrist-ice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200918235337.GA21189@sjchrist-ice> 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 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. > 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. 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? [*] https://lore.kernel.org/linux-sgx/20200918232458.GA6175@linux.intel.com/T/#u /Jarkko