From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758171AbcEFL1b (ORCPT ); Fri, 6 May 2016 07:27:31 -0400 Received: from mga09.intel.com ([134.134.136.24]:28624 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758061AbcEFL1a (ORCPT ); Fri, 6 May 2016 07:27:30 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,587,1455004800"; d="scan'208";a="98356483" Date: Fri, 6 May 2016 14:27:18 +0300 From: Jarkko Sakkinen To: Pavel Machek Cc: "Austin S. Hemmelgarn" , 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: <20160506112718.GC24074@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> <20160505225203.GC8494@intel.com> <20160506071443.GA32140@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160506071443.GA32140@amd> 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 Fri, May 06, 2016 at 09:14:43AM +0200, Pavel Machek wrote: > On Fri 2016-05-06 01:52:04, Jarkko Sakkinen wrote: > > 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. > > Umm. Now you are evil. > > Yes, the code that starts in the enclave may not be encrypted, but I'm > pretty sure the enclave will download some more code from remote > server after attestation... x86 or some kind of interpretted code. > > (But of course we already know that the technology is evil, as only > Intel can use it, see Ingo's reply.) Somehow that email from Ingo dissolved to my inbox :( Anyway, I gave now my response. For my part I'll create a second revision of the patch set and update the documentation so that it has reasonable explanation about root of trust SGX. > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html /Jarkko