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 4B81FC43441 for ; Sat, 24 Nov 2018 17:21:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1BDB120865 for ; Sat, 24 Nov 2018 17:21:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1BDB120865 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-sgx-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726017AbeKYEKm (ORCPT ); Sat, 24 Nov 2018 23:10:42 -0500 Received: from mga07.intel.com ([134.134.136.100]:11609 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725880AbeKYEKm (ORCPT ); Sat, 24 Nov 2018 23:10:42 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Nov 2018 09:21:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,273,1539673200"; d="scan'208";a="276509344" Received: from moellerb-mobl.ger.corp.intel.com (HELO localhost) ([10.249.254.169]) by orsmga005.jf.intel.com with ESMTP; 24 Nov 2018 09:21:21 -0800 Date: Sat, 24 Nov 2018 09:21:14 -0800 From: Jarkko Sakkinen To: Andy Lutomirski Cc: "Dr. Greg Wettstein" , X86 ML , Platform Driver , linux-sgx@vger.kernel.org, Dave Hansen , "Christopherson, Sean J" , nhorman@redhat.com, npmccallum@redhat.com, "Ayoun, Serge" , shay.katz-zamir@intel.com, haitao.huang@linux.intel.com, Andy Shevchenko , Thomas Gleixner , "Svahn, Kai" , mark.shanahan@intel.com, Suresh Siddha , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Darren Hart , Andy Shevchenko , LKML Subject: Re: [PATCH v17 18/23] platform/x86: Intel SGX driver Message-ID: <20181124172114.GB32210@linux.intel.com> References: <20181116010412.23967-1-jarkko.sakkinen@linux.intel.com> <20181116010412.23967-19-jarkko.sakkinen@linux.intel.com> <20181119161917.GF13298@linux.intel.com> <20181120120442.GA22172@linux.intel.com> <20181122111253.GA31150@wind.enjellic.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 Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: > > At a high level, addressing these issues is straight forward. First, > > the driver needs to support authorization equivalent to that which is > > implemented in the current Intel Launch Enclave, ie. control over the > > SGX_FLAGS_PROVISION_KEY attribute. > > I agree, hence my email :) Started to scratch my head that is it really an issue that any enclave can provision in the end? Direct quote from your first response: "In particular, the ability to run enclaves with the provisioning bit set is somewhat sensitive, since it effectively allows access to a stable fingerprint of the system." As can be seen from the key derivation table this does not exactly hold so you should refine your original argument before we can consider any type of change. I just don't see what it is so wrong for any enclave to be able to tell that it really is an enclave. /Jarkko From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarkko Sakkinen Subject: Re: [PATCH v17 18/23] platform/x86: Intel SGX driver Date: Sat, 24 Nov 2018 09:21:14 -0800 Message-ID: <20181124172114.GB32210@linux.intel.com> References: <20181116010412.23967-1-jarkko.sakkinen@linux.intel.com> <20181116010412.23967-19-jarkko.sakkinen@linux.intel.com> <20181119161917.GF13298@linux.intel.com> <20181120120442.GA22172@linux.intel.com> <20181122111253.GA31150@wind.enjellic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski Cc: "Dr. Greg Wettstein" , X86 ML , Platform Driver , linux-sgx@vger.kernel.org, Dave Hansen , "Christopherson, Sean J" , nhorman@redhat.com, npmccallum@redhat.com, "Ayoun, Serge" , shay.katz-zamir@intel.com, haitao.huang@linux.intel.com, Andy Shevchenko , Thomas Gleixner , "Svahn, Kai" , mark.shanahan@intel.com, Suresh Siddha , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Darren Hart , Andy Shevchenko , LKML List-Id: platform-driver-x86.vger.kernel.org On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: > > At a high level, addressing these issues is straight forward. First, > > the driver needs to support authorization equivalent to that which is > > implemented in the current Intel Launch Enclave, ie. control over the > > SGX_FLAGS_PROVISION_KEY attribute. > > I agree, hence my email :) Started to scratch my head that is it really an issue that any enclave can provision in the end? Direct quote from your first response: "In particular, the ability to run enclaves with the provisioning bit set is somewhat sensitive, since it effectively allows access to a stable fingerprint of the system." As can be seen from the key derivation table this does not exactly hold so you should refine your original argument before we can consider any type of change. I just don't see what it is so wrong for any enclave to be able to tell that it really is an enclave. /Jarkko