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