Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp182672yba; Wed, 15 May 2019 22:03:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqypOo+bLF6qjl7aouOOjfZbpfUnhrh9783h1SG9z0NICCFb1ywpUszjJoC55guAiv1+9sds X-Received: by 2002:a17:902:7082:: with SMTP id z2mr24862870plk.176.1557983027500; Wed, 15 May 2019 22:03:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557983027; cv=none; d=google.com; s=arc-20160816; b=MG8vgeANVpc8AiqGCEect/R/kpJtKNt6bfLLGVWIdjOMpo1o/GlkcFH/XuA3oGBieF WalyaRFirpIIrdvt4Qz4y9A0EMgCYGcJtOgog+7clc79PIhoEDNklfTXDhxIk20vL5UH hbuc28EIQaGlCN08Mbla8FdeXZHLuBdQktpkx9ED/Dtt3V5kOeXQ3lY8cU+AysbKcMoB r1au7TCfKWxNUOxdIDkHldfnXPTRgsBMwUsfXVik2bdKusGzh72h6yffZY/CPr2NelJa ee+tfi/8mCGgq7/+wAnSUR/6p97thnrb7dU1RaS9yQa3amF4/ynqWb2ldUgiztXwqIsn SPXg== 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=0KiIAZ4LkXGPqHlWHIduGr06BShtYQdQZFViEp+so/o=; b=sfW0pehXT9+Bb/jW491eTjRM3/hjvR7z35Fd3XNQRuwXm3N4PyUMBW31m4ZKX3vbFp vmLguKv42NQxnpp+Ib3wdwEnM3UJPy+dqyg4abVXFAI6m3wzbpDo78h8aLKzdpW7e15O xiF8Gx+WwRgunTQFmgf+YgF1ojjVygN6XF5g9mWjgcI4xl6tLKGXR3U3uBRQQ2V5BskB xSMmk/R22cJAHQnFIR5uSQ26jFvF+jtEs+8hObsAjdthDnuYyOgHDUMIgCPtgVttuZaY xfNnhpAArwTpP56butFbdcJOrmJE19A6shHyg9PJCwebmJJ/M9MvAForP/Yfm+EEXqdJ /1VA== 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 r26si3873948pgb.32.2019.05.15.22.03.31; Wed, 15 May 2019 22:03:47 -0700 (PDT) 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 S1726400AbfEPFBq (ORCPT + 99 others); Thu, 16 May 2019 01:01:46 -0400 Received: from mga18.intel.com ([134.134.136.126]:50290 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725975AbfEPFBq (ORCPT ); Thu, 16 May 2019 01:01:46 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2019 22:01:45 -0700 X-ExtLoop1: 1 Received: from jsakkine-mobl1.tm.intel.com (HELO localhost) ([10.237.50.189]) by fmsmga008.fm.intel.com with ESMTP; 15 May 2019 22:01:40 -0700 Date: Thu, 16 May 2019 08:01:50 +0300 From: Jarkko Sakkinen To: Sean Christopherson Cc: Andy Lutomirski , Jethro Beekman , "Xing, Cedric" , "Hansen, Dave" , Thomas Gleixner , "Dr. Greg" , Linus Torvalds , LKML , X86 ML , "linux-sgx@vger.kernel.org" , Andrew Morton , "nhorman@redhat.com" , "npmccallum@redhat.com" , "Ayoun, Serge" , "Katz-zamir, Shay" , "Huang, Haitao" , Andy Shevchenko , "Svahn, Kai" , Borislav Petkov , Josh Triplett , "Huang, Kai" , David Rientjes Subject: Re: [PATCH v20 00/28] Intel SGX1 support Message-ID: <20190516050150.GA6388@linux.intel.com> References: <358e9b36-230f-eb18-efdb-b472be8438b4@fortanix.com> <960B34DE67B9E140824F1DCDEC400C0F4E886094@ORSMSX116.amr.corp.intel.com> <6da269d8-7ebb-4177-b6a7-50cc5b435cf4@fortanix.com> <20190513102926.GD8743@linux.intel.com> <20190514104323.GA7591@linux.intel.com> <20190514204527.GC1977@linux.intel.com> <20190515103531.GB10917@linux.intel.com> <20190515132147.GA5875@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190515132147.GA5875@linux.intel.com> 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 Wed, May 15, 2019 at 06:21:47AM -0700, Sean Christopherson wrote: > On Wed, May 15, 2019 at 01:35:31PM +0300, Jarkko Sakkinen wrote: > > On Tue, May 14, 2019 at 01:45:27PM -0700, Sean Christopherson wrote: > > > On Tue, May 14, 2019 at 08:13:36AM -0700, Andy Lutomirski wrote: > > > > I think it's as simple as requiring that, if SECINFO.X is set, then > > > > the src pointer points to the appropriate number of bytes of > > > > executable memory. (Unless there's some way for an enclave to change > > > > SECINFO after the fact -- is there?) > > > > > > Nit: SECINFO is just the struct passed to EADD, I think what you're really > > > asking is "can the EPCM permissions be changed after the fact". > > > > > > And the answer is, yes. > > > > > > On SGX2 hardware, the enclave can extend the EPCM permissions at runtime > > > via ENCLU[EMODPE], e.g. to make a page writable. > > > > Small correction: it is EMODPR. > > No, I'm referring to EMODPE, note the ENCLU classification. > > > Anyway, it is good to mention that these would require EACCEPT from the > > enclave side. In order to take advantage of this is in a malicous > > enclave, one would require SELinux/IMA/whatnot policy to have permitted > > it in the first place. > > EMODPE doesn't require EACCEPT or any equivalent from the kernel. As > you alluded to, the page tables would still need to allow PROT_EXEC. I > was simply trying to answer Andy's question regarding SECINFO. Ah, have to admit that I had totally forgot EMODPE :-) Have not had to deal with that opcode that much. /Jarkko