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=unavailable 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 2BCCBC04AB7 for ; Tue, 14 May 2019 10:43:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0A19420881 for ; Tue, 14 May 2019 10:43:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726529AbfENKnZ (ORCPT ); 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