From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757883AbcEEWwO (ORCPT ); Thu, 5 May 2016 18:52:14 -0400 Received: from mga02.intel.com ([134.134.136.20]:14507 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755736AbcEEWwM (ORCPT ); Thu, 5 May 2016 18:52:12 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,584,1455004800"; d="scan'208";a="799862810" Date: Fri, 6 May 2016 01:52:04 +0300 From: Jarkko Sakkinen To: "Austin S. Hemmelgarn" Cc: Pavel Machek , gregkh@linuxfoundation.org, Andy Lutomirski , Borislav Petkov , Boris Ostrovsky , "open list:STAGING SUBSYSTEM" , Ingo Molnar , Kristen Carlson Accardi , "open list:DOCUMENTATION" , open list , Mathias Krause , Thomas Gleixner , Wan Zongshun Subject: Re: [PATCH 0/6] Intel Secure Guard Extensions Message-ID: <20160505225203.GC8494@intel.com> References: <1461605698-12385-1-git-send-email-jarkko.sakkinen@linux.intel.com> <20160426190009.GC8162@amd> <20160429201744.GD27821@intel.com> <142feb98-3a97-0b00-0b17-b029fa2c637f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <142feb98-3a97-0b00-0b17-b029fa2c637f@gmail.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 02, 2016 at 11:37:52AM -0400, Austin S. Hemmelgarn wrote: > On 2016-04-29 16:17, Jarkko Sakkinen wrote: > >On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote: > >>On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote: > >>>Intel(R) SGX is a set of CPU instructions that can be used by > >>>applications to set aside private regions of code and data. The code > >>>outside the enclave is disallowed to access the memory inside the > >>>enclave by the CPU access control. > >>> > >>>The firmware uses PRMRR registers to reserve an area of physical memory > >>>called Enclave Page Cache (EPC). There is a hardware unit in the > >>>processor called Memory Encryption Engine. The MEE encrypts and decrypts > >>>the EPC pages as they enter and leave the processor package. > >> > >>What are non-evil use cases for this? > > > >I'm not sure what you mean by non-evil. > > > I would think that this should be pretty straightforward. Pretty much every > security technology integrated in every computer in existence has the > potential to be used by malware for various purposes. Based on a cursory > look at SGX, it is pretty easy to figure out how to use this to hide > arbitrary code from virus scanners and the OS itself unless you have some > way to force everything to be a debug enclave, which entirely defeats the > stated purpose of the extensions. I can see this being useful for tight > embedded systems. On a desktop which I have full control of physical access > to though, it's something I'd immediately turn off, because the risk of > misuse is so significant (I've done so on my new Thinkpad L560 too, although > that's mostly because Linux doesn't support it yet). The code in enclave binary is in clear text so it does not really allow you to completely hide any code. It's a signed binary, not encypted binary. /Jarkko