Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3066511imu; Mon, 17 Dec 2018 12:41:08 -0800 (PST) X-Google-Smtp-Source: AFSGD/WPvRxQYxXiSPmm45VmXRWqYpgQlB5cmCKpoIHmfKYigqj49/1zxMw23v89XjCPfUCdvaiY X-Received: by 2002:a62:d74d:: with SMTP id v13mr13865313pfl.34.1545079268867; Mon, 17 Dec 2018 12:41:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545079268; cv=none; d=google.com; s=arc-20160816; b=gD3QdmooveLkBNbVwEGb7r8xJ1DpUUX/M8utCUuf5eNjaapWZ6/MnneYyOoFcG4zXW 8NETMOrxNPOdxy3CPf5NFPdvsiqjum1/ZtWA1ridnaKInWStAkxBd+2Hyy7e5bBnb2MV cgyJqr/Uny6OSaoDlaV132Dy05mBVTN0eq7Z460E9ykUx7JXy+0VbfraWFBSd2WYbGJW YfG2+Erx7NUmy+w1MXbSamx+PAbO7X4KDTKAoMN5Uvgj4dKZ7L1ntbxnOOa2kap4XbLK 28TbQ8Pu041sS5fqhuM8oJ/qwWJjyayQq4qtJtJGokRx9RiXl/7NdXwv+V/Soaxc2t4M 81zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=L3jWfHsn8M+XsyItdfvMvlkTjdRC5OeJ2o1bzgeckAY=; b=YPhmQ62fTl80QW8kQI3vLkWFlhIsV/BR12fG7yhMSpG5dvE41Bf3Kt8nnV79Vb2GpJ d99QK/Gtu98CaL7H23ZNdNrQvhVHNK89Q9OqD/2oJj+gb2z2gRa4dicxRMMYyzxjBqRx oo8kDzz3DNCsralIFgTKHtyBFsuYeGbQ1/AI7/ZUXhYYD1Vs6TeiGqElJ69xOkLkWWyc XshKZzemzprYGw6u8nEh6if4721rA7jiN6PJb/BttTtzOLR3Ws/cl9OQLtk6dR/QXqAQ +3Q4dCLSEbaDLW1PyCc1LK2Sgm0xXQlOzC+XfOjP8kBzl5JxtGRR7Nw6Cs/BgfGixB12 3bLQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t74si11874979pgc.150.2018.12.17.12.40.53; Mon, 17 Dec 2018 12:41:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388511AbeLQTtV (ORCPT + 99 others); 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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