Re: [PATCH 0/6] Intel Secure Guard Extensions

From: Jarkko Sakkinen
Date: Thu May 05 2016 - 18:52:17 EST

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.