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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham 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 0BEAFC43387 for ; Mon, 17 Dec 2018 19:49:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D97E621473 for ; Mon, 17 Dec 2018 19:49:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731928AbeLQTtV (ORCPT ); Mon, 17 Dec 2018 14:49:21 -0500 Received: from mga07.intel.com ([134.134.136.100]:25774 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727060AbeLQTtV (ORCPT ); Mon, 17 Dec 2018 14:49:21 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2018 11:49:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,366,1539673200"; d="scan'208";a="101389785" Received: from quwen-mobl.ccr.corp.intel.com (HELO localhost) ([10.249.254.215]) by orsmga006.jf.intel.com with ESMTP; 17 Dec 2018 11:49:14 -0800 Date: Mon, 17 Dec 2018 21:49:13 +0200 From: Jarkko Sakkinen To: Dave Hansen Cc: Andy Lutomirski , Sean Christopherson , X86 ML , Platform Driver , linux-sgx@vger.kernel.org, nhorman@redhat.com, npmccallum@redhat.com, "Ayoun, Serge" , shay.katz-zamir@intel.com, Haitao Huang , Andy Shevchenko , Thomas Gleixner , "Svahn, Kai" , mark.shanahan@intel.com, Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Darren Hart , Andy Shevchenko , "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" Subject: Re: [PATCH v17 18/23] platform/x86: Intel SGX driver Message-ID: <20181217194913.GD29785@linux.intel.com> References: <20181116010412.23967-1-jarkko.sakkinen@linux.intel.com> <20181116010412.23967-19-jarkko.sakkinen@linux.intel.com> <7d5cde02-4649-546b-0f03-2d6414bb80b5@intel.com> <20181217180102.GA12560@linux.intel.com> <20181217183613.GD12491@linux.intel.com> <20181217184333.GA26920@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-sgx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On Mon, Dec 17, 2018 at 11:17:49AM -0800, Dave Hansen wrote: > On 12/17/18 11:12 AM, Andy Lutomirski wrote: > > So I'm not saying that you shouldn't do it the way you are now, but I > > do think that the changelog or at least some emails should explain > > *why* the enclave needs to keep a pointer to the creating process's > > mm. And, if you do keep the current model, it would be nice to > > understand what happens if you do something awful like mremap()ing an > > enclave, or calling madvise on it, or otherwise abusing the vma. Or > > doing fork(), for that matter. > > Yeah, the code is built to have one VMA and only one VMA per enclave. > You need to go over the origin of this restriction and what enforces this. It is before ECREATE but after that you can split it with mprotect(). Lets take an example. I'm not sure how we would acquire mm efficiently in sgx_encl_page_reclaim() otherwise than having it as a field in encl. /Jarkko