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 67FF1C2D0E2 for ; Wed, 23 Sep 2020 13:31:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9A8D42220D for ; Wed, 23 Sep 2020 13:31:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9A8D42220D 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 D334E6B0003; Wed, 23 Sep 2020 09:31:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CBB8A6B0055; Wed, 23 Sep 2020 09:31:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BAB256B005A; Wed, 23 Sep 2020 09:31:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0170.hostedemail.com [216.40.44.170]) by kanga.kvack.org (Postfix) with ESMTP id A4D576B0003 for ; Wed, 23 Sep 2020 09:31:11 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5AABC362D for ; Wed, 23 Sep 2020 13:31:11 +0000 (UTC) X-FDA: 77294412342.13.kite62_3101a4527156 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 3BB3618140B60 for ; Wed, 23 Sep 2020 13:31:11 +0000 (UTC) X-HE-Tag: kite62_3101a4527156 X-Filterd-Recvd-Size: 4612 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Sep 2020 13:31:09 +0000 (UTC) IronPort-SDR: kNN2j/bR0nqQr654HcccGjmjWqi0XeLaYtwU3GjVlHU74STMAkpLtioND8oiayaspfKCqv84Ii DV7I7NxQkQhA== X-IronPort-AV: E=McAfee;i="6000,8403,9752"; a="140351634" X-IronPort-AV: E=Sophos;i="5.77,293,1596524400"; d="scan'208";a="140351634" 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; 23 Sep 2020 06:31:08 -0700 IronPort-SDR: Uj5lNb/86HNoXNl0NOZ1QzuO25rPsPO40SiyFdWUt2yP40x3KowyctRG3E7q7xNzTNmpxGmzhA mYsBi72ufEKw== X-IronPort-AV: E=Sophos;i="5.77,293,1596524400"; d="scan'208";a="486442114" Received: from ichiojdo-mobl.ger.corp.intel.com (HELO localhost) ([10.252.51.82]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2020 06:31:01 -0700 Date: Wed, 23 Sep 2020 16:30:59 +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: <20200923133059.GB5160@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25d46fdc-1c19-2de8-2ce8-1033a0027ecf@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 Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote: > > Enclave permissions can be dynamically modified by using ENCLS[EMODPE] > > I'm not sure this sentence matters. I'm not sure why I care what the > instruction is named that does this. But, it _sounds_ here like an > enclave can adjust its own permissions directly with ENCLS[EMODPE]. If there was no EMODPE, I would drop this patch from the patch set. It is the only reason I keep it. There are no other hard reasons to have this. > Now I'm confused. I actually don't think I have a strong understanding > of how an enclave actually gets loaded, how mmap() and mprotect() are > normally used and what this hook is intended to thwart. Enclave gets loaded with the ioctl API so ATM we rely only on DAC permissions. In future you might want to have LSM hooks to improve granularity in two points: 1. When pages are added using SGX_IOC_ENCLAVE ADD_PAGES. 2. When enclave is initialized using SGX_IOC_ENCLAVE_INIT In both you might want to make a policy decision based on origin and page permissions. If we do not limit mmap(), enclave could later on upgrade its permissions with EMODPE and do mmap(). No matter what kind of LSM hooks or whatever possible improvements are done later on to access control, they won't work unless we have this because the permissions could be different than the original. With this change you can still do EMODPE inside an enclave, but you don't gain anything with it because your max permissions are capped during the build time. I'm not sure what exactly from this is missing from the commit message but if you get this explanation maybe you can help me out with that. Thank you for the feedback. /Jarkko