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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
