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 8852CC4363D for ; Thu, 24 Sep 2020 19:36:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1C34E2220C for ; Thu, 24 Sep 2020 19:36:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C34E2220C 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 7D3E16B0068; Thu, 24 Sep 2020 15:36:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7846B6B006C; Thu, 24 Sep 2020 15:36:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69C346B006E; Thu, 24 Sep 2020 15:36:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0176.hostedemail.com [216.40.44.176]) by kanga.kvack.org (Postfix) with ESMTP id 53F426B0068 for ; Thu, 24 Sep 2020 15:36:10 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1133F180AD801 for ; Thu, 24 Sep 2020 19:36:10 +0000 (UTC) X-FDA: 77298960900.20.idea14_60154ac27161 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id EADD2180C07AB for ; Thu, 24 Sep 2020 19:36:09 +0000 (UTC) X-HE-Tag: idea14_60154ac27161 X-Filterd-Recvd-Size: 6488 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Thu, 24 Sep 2020 19:36:09 +0000 (UTC) IronPort-SDR: KtBUQydUGcUzlGP5EW+TPiiNsMEK+7EyeqvomuJdvliDRKPUwajX2AlMpDLBeuRoP4xc0zk9hj UlCmS5EEnFKg== X-IronPort-AV: E=McAfee;i="6000,8403,9754"; a="140751988" X-IronPort-AV: E=Sophos;i="5.77,299,1596524400"; d="scan'208";a="140751988" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Sep 2020 12:36:06 -0700 IronPort-SDR: Sczp8wrchpz0ERElmw8nWUtsvYklYfxRPSH36aWj7z0OejBff7FDAegpBr9hg4TR0RbhATb7yN lguyZnRvAWZw== X-IronPort-AV: E=Sophos;i="5.77,299,1596524400"; d="scan'208";a="487065236" Received: from deepamin-mobl1.gar.corp.intel.com (HELO localhost) ([10.252.44.18]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Sep 2020 12:35:59 -0700 Date: Thu, 24 Sep 2020 22:35:57 +0300 From: Jarkko Sakkinen To: Dave Hansen Cc: Andy Lutomirski , Sean Christopherson , 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: <20200924193557.GA108958@linux.intel.com> References: <20200918235337.GA21189@sjchrist-ice> <1B23E216-0229-4BDD-8B09-807256A54AF5@amacapital.net> <20200922125801.GA133710@linux.intel.com> <25d46fdc-1c19-2de8-2ce8-1033a0027ecf@intel.com> <20200923143305.GE5160@linux.intel.com> <982367fb-17b7-a647-a33b-8c8e5e1511a2@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <982367fb-17b7-a647-a33b-8c8e5e1511a2@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 Thu, Sep 24, 2020 at 07:50:15AM -0700, Dave Hansen wrote: > On 9/23/20 7:33 AM, Jarkko Sakkinen wrote: > > The consequence is that enclaves are best created with an ioctl API and the > > access control can be based only to the origin of the source file for the > > enclave data, i.e. on VMA file pointer and page permissions. For example, > > this could be done with LSM hooks that are triggered in the appropriate > > ioctl's and they could make the access control decision based on this > > information. > > > > Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to > > upgrade its permissions. If we do not limit mmap() and mprotect(), enclave > > could upgrade its permissions by using EMODPE followed by an appropriate > > mprotect() call. This would be completely hidden from the kernel. > > > > Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX > > that will ensure that {mmap, mprotect}() permissions do not surpass any of > > the original page permissions. This feature allows to maintain and refine > > sane access control for enclaves. > > Maybe I'm just being dense, but I still don't have a clear idea what > function this hook serves. > > I understand that SGX has an orthogonal set of page permissions to the > normal x86 page tables. It needs these so that the OS can't play nasty > tricks on the enclave, like removing read-only protections that provide > hardening. > > But, I still don't get the connection to mprotect() and the x86 paging > permissions. If the enclave's permissions are orthogonal, then why > bother with this hook? Why does the OS view of the enclave's memory matter? Consider SGX_IOC_ENCLAVE_ADD_PAGES. It essentially takes from MAC perpective two items: 1. Source represented as a VMA, and in the end as vm_file, i.e. the origin. This good place to anchor a security policy. 2. Permissions. Since enclaves are dynamically constructed and do not go through execve() path but are dynamically loaded this is a good place hook make an LSM hook. Lets imagine that we have an LSM hook in place. Now when enclave the enclave is loaded the LSM makes decisions based on its policy, permissions and the origin of the enclave file. After this decisions has been made it is sane to assume that the enclave could not be run with higher permissions, right? Now what an adversary could do after the enclave has been loaded and initialized is to call EMODPE inside the enclave to upgrade permissions to some pages. After that mprotect() can be applied to use the new permissions. The mprotect() callback keeps any higher permissions than originally accepted by the MAC policy unusable. Also without any LSM hooks this allows to have a more privileged launcher process to build enclaves (e.g. have someone to own /dev/sgx/enclave) and send fd's to other processes to run them. And with that callback in place the launcher process can cap the permissions at build time. That's where the indirect connection originates from. Should I write this user story to the commit message as an addition. Would that help? For v39 I did make a change that noexec partitions are categorically discluded as an origin for enclaves. Before that it was that NX pages from such partitions are allowed but I thought that it is better simplify things since they are anyway complex. I'm 100% we can make that kind of support for noexec partitions later on, if anyone ever wants that anyway. /Jarkko