Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6208676yba; Tue, 14 May 2019 03:45:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqxztEZtsS1cADhYe7QBr75NJoIJygoWmy6jjTYL0O1qnm6gxVPhG8hWaMY3EhjHdHjXaTgY X-Received: by 2002:a63:7d18:: with SMTP id y24mr22749966pgc.101.1557830739165; Tue, 14 May 2019 03:45:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557830739; cv=none; d=google.com; s=arc-20160816; b=RxVRfjMdzzpTv1ZIG4bzkw7LDW18KVfJVnsGsYxnZttBsYa62JcgdOP6UEg5CXxty5 FOkFEDvszuKJ+W/aJqaEo+ZxacFfeU5YPK6JSdSHwsHlRrAEBBYKcPZXHCKN6Z5+RXeN LPUGfgVVc/3lct31YWSIGW2BtPlU5xnS9O4kyQprDwQx7PMLITwgrv7wOAU6LT6aUgfp XinZT0mQ/Vx4KgMbPDqL2hsDSpM7YfHqStWVCaNJd69Qn8wOAL+3tXW8iPaBMLjEKiA7 7Ib0kR+rpbpbHWaYchxVHJjfjq183m/XqjFzWTH7idg/sMZvbpb0vwCOpcYmwRXjcjHB wtQw== 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=g/dqrtgROiIOmTjnIofDzevoOuq/qSAVC3lGLQEpit0=; b=VYVf9SJ4QaQ1eaGC+/CfFDWzJA0Uz+N738kc4M1DQyWC+bHcpkCX/SyJ3dlJlP+pDJ 02oaRGBecRA1A55/B3aIHKfL2CHvoiWThmnEkoEa05oj/3g9gDMRyMbmvllGobbvbcaO MIeSSHU8pJipmbb5d+OKl3ZsinwWhQehLzwfABDjEMmcG8xSqsOdjSYFjXGWfbK4uYxN zxBWQRiKRMxbX3vwtFTAVdZfcja3Jvdyew1Uruk1Uk8VbX+sNr+J0mSnqY2ffEWPtiYL /k4278fbrBW7JtW9/y5by47Bc7XKWHkvOsqCw2t00IPMnLIQ1ZCBRZ6oMmEKES8iGJEm 96Vg== 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 l21si20656685pgc.190.2019.05.14.03.45.24; Tue, 14 May 2019 03:45:39 -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 S1726517AbfENKnZ (ORCPT + 99 others); Tue, 14 May 2019 06:43:25 -0400 Received: from mga07.intel.com ([134.134.136.100]:49549 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725893AbfENKnZ (ORCPT ); Tue, 14 May 2019 06:43:25 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2019 03:43:24 -0700 X-ExtLoop1: 1 Received: from jsakkine-mobl1.tm.intel.com (HELO localhost) ([10.237.50.189]) by orsmga008.jf.intel.com with ESMTP; 14 May 2019 03:43:16 -0700 Date: Tue, 14 May 2019 13:43:23 +0300 From: Jarkko Sakkinen To: Andy Lutomirski Cc: Jethro Beekman , "Xing, Cedric" , "Hansen, Dave" , Thomas Gleixner , "Dr. Greg" , Linus Torvalds , LKML , X86 ML , "linux-sgx@vger.kernel.org" , Andrew Morton , "Christopherson, Sean J" , "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: <20190514104323.GA7591@linux.intel.com> References: <5854e66a-950e-1b12-5393-d9cdd15367dc@fortanix.com> <960B34DE67B9E140824F1DCDEC400C0F4E885F9D@ORSMSX116.amr.corp.intel.com> <979615a8-fd03-e3fd-fbdb-65c1e51afd93@fortanix.com> <8fe520bb-30bd-f246-a3d8-c5443e47a014@intel.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190513102926.GD8743@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 Mon, May 13, 2019 at 01:29:26PM +0300, Jarkko Sakkinen wrote: > I did study through SDK's file format and realized that it does not > does make sense after all to embed one. > > To implement it properly you would probably need a new syscall (lets say > sgx_load_enclave) and also that enclaves are not just executables > binaries. It is hard to find a generic format for them as applications > range from simply protecting part of an application to running a > containter inside enclave. When I looked at SDK's data structures embedded to the ELF they contain data that is also used by the run-time. Thus, run-time would anyway need to also parse the file containing the enclave. There is not same way a single rigid structure of what executable means as for normal application and in many cases enclave could be just used to seal a portion of the code. In extreme case you might construct enclave even on run-time. I think SIGSTRUCT in a file is the right choice. It is the lowest common denominator for enclaves that locks in its contents and is same for any enclave. Practicing access control to that file should be enough to define whatever security policy required. I'm still puzzling what kind of changes you were discussing considering SGX_IOC_ENCLAVE_ADD_PAGE. /Jarkko