From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755010AbdLTKNP (ORCPT ); Wed, 20 Dec 2017 05:13:15 -0500 Received: from mga09.intel.com ([134.134.136.24]:17389 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754981AbdLTKNK (ORCPT ); Wed, 20 Dec 2017 05:13:10 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,431,1508828400"; d="scan'208";a="160358224" Date: Wed, 20 Dec 2017 12:13:05 +0200 From: Jarkko Sakkinen To: "Christopherson, Sean J" Cc: "linux-kernel@vger.kernel.org" , "intel-sgx-kernel-dev@lists.01.org" , "platform-driver-x86@vger.kernel.org" Subject: Re: [intel-sgx-kernel-dev] [PATCH v5 06/11] intel_sgx: driver for Intel Software Guard Extensions Message-ID: <20171220101305.tgx5fre3ugqaudd4@linux.intel.com> References: <20171113194528.28557-1-jarkko.sakkinen@linux.intel.com> <20171113194528.28557-7-jarkko.sakkinen@linux.intel.com> <1510682106.3313.24.camel@intel.com> <20171114202835.64rl35asldh3jgui@linux.intel.com> <1510770027.11044.37.camel@intel.com> <37306EFA9975BE469F115FDE982C075BC6B3B5E6@ORSMSX108.amr.corp.intel.com> <20171215150020.e3vq5fh2rtydzhkt@linux.intel.com> <37306EFA9975BE469F115FDE982C075BCDEE4562@ORSMSX114.amr.corp.intel.com> <1513725073.2206.13.camel@linux.intel.com> <37306EFA9975BE469F115FDE982C075BCDEE4742@ORSMSX114.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37306EFA9975BE469F115FDE982C075BCDEE4742@ORSMSX114.amr.corp.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 19, 2017 at 11:24:55PM +0000, Christopherson, Sean J wrote: > Exposing the token generated by the in-kernel LE doesn't affect the > kernel's power in the slightest, e.g. the kernel doesn't need a LE > to refuse to run an enclave and a privileged user can always load > an out-of-tree driver if they really want to circumvent the kernel's > policies, which is probably easier than stealing the LE's private key. If the MSRs are read-only, kernel does need an LE in order to launch enclaves if it only has the SIGSTRUCT. User with abilities to load out-of-tree driver or otherwise modify the running kernel code does not really work as an argument in to any direction. /Jarkko