topic Demonstrating memory protection in Intel® Software Guard Extensions (Intel® SGX)

Demonstrating memory protection

sj — Sat, 11 Jul 2020 21:03:11 GMT

Hi,

I was trying to understand the memory protections available for SGX. While it is theoretically clear, I am unable to validate this using a simple example. My goal was to embed a string inside the enclave and ensure that the string is not visible in a process dump. But it seems that the string and any operations done on it are completely visible in the process dump on the Windows platform.

I read in a post on this forum that this is expected in Debug mode - but the memory protections are enabled in Pre-Release mode (https://community.intel.com/t5/Intel-Software-Guard-Extensions/Is-not-memory-protection-in-debug-mode/td-p/1152059). I have tried both, but the result is the same for both times. I've done my experiments by modifying the standard ConsoleApp example.

Is there something I am missing in the settings or is this not possible compiling in Release mode, i.e. without the Intel Commercial Agreement?

Thanks

Re:Demonstrating memory protection

JesusG_Intel — Mon, 13 Jul 2020 17:39:07 GMT

Hello SJ,

It is strange that you can see the contents of the enclave using a process dump since this is possible only in Simulation Mode. A debugger or other software must use the CPU instructions EDBGRD to read from a debug enclave and EDBGWR to write to a debug enclave. The SGX Debugger implements these instructions to see into enclaves.

Read this page, https://software.intel.com/content/www/us/en/develop/blogs/intel-sgx-debug-production-prelease-whats-the-difference.html, for more info on the differences between the different compilation modes.

Re: Re:Demonstrating memory protection

sj — Tue, 14 Jul 2020 15:31:27 GMT

Hello Jesus,

This is quite strange - I'd have expected different behavior. I have verified all the settings on my machine. The machine definitely supports SGX, it is enabled and I am linking against the regular SGX libraries (non sim variants).

Any ideas on how this can be debugged? Am I missing something or is something configured incorrectly. This is quite essential because all future work would depend on the proper usage of SGX.

I am attaching the VS2017 project I am referring to that should show all my build settings. The CPUID command output is posted below. I have also created a small video that shows the steps I have taken and exactly what I am seeing in the memory dump.

I am basically embedding a secret string in the enclave. Within the enclave, I am doing the operation of reversing the last few characters of the string. Both the original and processed strings are visible in the memory dump.

Thanks for your help

-Shalabh

Project: Attached

Video Description: https://youtu.be/XYZmo7IpazE

CPUID dump

0 EAX(0016) EBX(756e6547) ECX(6c65746e) EDX(49656e69)
1 EAX(406e3) EBX(2100800) ECX(7ffafbff) EDX(bfebfbff)
2 EAX(76036301) EBX(f0b5ff) ECX(0000) EDX(c30000)
3 EAX(0000) EBX(0000) ECX(0000) EDX(0000)
4 EAX(1c004121) EBX(1c0003f) ECX(003f) EDX(0000)
5 EAX(0040) EBX(0040) ECX(0003) EDX(11142120)
6 EAX(27f7) EBX(0002) ECX(0009) EDX(0000)
7 EAX(0000) EBX(29c6fbf) ECX(0000) EDX(9c002400)
8 EAX(0000) EBX(0000) ECX(0000) EDX(0000)
9 EAX(0000) EBX(0000) ECX(0000) EDX(0000)
10 EAX(7300404) EBX(0000) ECX(0000) EDX(0603)
11 EAX(0001) EBX(0002) ECX(0100) EDX(0003)
12 EAX(0000) EBX(0000) ECX(0000) EDX(0000)
13 EAX(001f) EBX(0440) ECX(0440) EDX(0000)
14 EAX(0000) EBX(0000) ECX(0000) EDX(0000)
15 EAX(0000) EBX(0000) ECX(0000) EDX(0000)
16 EAX(0000) EBX(0000) ECX(0000) EDX(0000)
17 EAX(0000) EBX(0000) ECX(0000) EDX(0000)
18 EAX(0001) EBX(0000) ECX(0000) EDX(241f)
19 EAX(0000) EBX(0000) ECX(0000) EDX(0000)
20 EAX(0001) EBX(000f) ECX(0007) EDX(0000)
21 EAX(0002) EBX(00d0) ECX(0000) EDX(0000)

Re:Demonstrating memory protection

JesusG_Intel — Thu, 16 Jul 2020 21:10:25 GMT

Hi SJ,

We are investigating your issue. Please stay tuned.

Re:Demonstrating memory protection

JesusG_Intel — Thu, 16 Jul 2020 23:26:46 GMT

Hello SJ,

It took me a while but I finally found the answer: https://community.intel.com/t5/Intel-Software-Guard-Extensions/ENCLAVE-DATA-STORAGE/m-p/1133763/highlight/true#M1971.

Basically, "any variables initialized at compile time will be in the clear in the enclave binary, as that is not encrypted in any way."

Re:Demonstrating memory protection

JesusG_Intel — Thu, 16 Jul 2020 23:53:18 GMT

SJ,

There is more information on this in the Intel SGX Developer Reference for Windows. The section "Enabling Enclave Code Confidentiality" states that:

"Intel® SGX provides integrity of code and confidentiality and integrity of data at run-time. However, it does NOT provide confidentiality of code offline as a binary file on disk."

The solution, if you must use a global variable with secret data, is to encrypt the enclave DLL at build time then decrypt it at enclave load time using the Intel SGX Protected Code Loader.

Re: Re:Demonstrating memory protection

sj — Fri, 17 Jul 2020 09:47:35 GMT

Hello Jesus,

This is not a matter of checking at rest - its the memory dump computed during execution.

It is clear that to encrypt the secrets at rest we need to use PCL or something similar - but the problem I am raising is that the runtime memory is visible. This means that any operation done on static variables (e.g. reversing it in the video I uploaded) is also visible. This is not the expected behaviour. This is basically indicative of no runtime protections.

Please have a look at the video I uploaded.

Re:Demonstrating memory protection

JesusG_Intel — Fri, 17 Jul 2020 18:17:13 GMT

You are correct, SJ. I confused code at rest on disk with code in memory.

We are investigating your issue further and will respond to you as soon as I have an answer.

Re: Re:Demonstrating memory protection

sj — Fri, 17 Jul 2020 18:53:17 GMT

Thank you Jesus. I appreciate the efforts.

Re:Demonstrating memory protection

JesusG_Intel — Thu, 23 Jul 2020 18:15:06 GMT

This thread has been marked as answered and Intel will no longer monitor this thread. If you want a response from Intel in a follow-up question, please open a new thread.

Hello SJ,

This is indeed expected behavior in Windows 10. This paper, https://silo.tips/download/intel-sgx-enclave-support-in-windows-10-fall-update-threshold-2, explains it in the section "Debugging Enclaves."

Basically, Microsoft owns the SGX driver for Windows and in Windows 10 they implemented their memory readers -- such as WinDBG, and other processes that read memory -- to recognize when they are reading into an Enclave. So, Microsoft is calling the functions I listed above, EDBGRD and EDBGWR, to see inside the Enclave.

This only happens for non-Release/non-Production enclaves. In a full production enclave, the EDBGRD and EDBGWR instructions will not work so a process dump from Windows will not reveal what is inside the enclave.

Re: Demonstrating memory protection

Ray1 — Mon, 26 Oct 2020 08:44:26 GMT

Have you applied for the SGX commercial license? The Release model seems to require a commercial license