Community
cancel
Showing results for 
Search instead for 
Did you mean: 
sj
Beginner
463 Views

Demonstrating memory protection

Jump to solution

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-mod...). 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

SJ

0 Kudos

Accepted Solutions
JesusG_Intel
Moderator
371 Views

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.

 

View solution in original post

10 Replies
JesusG_Intel
Moderator
442 Views

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..., for more info on the differences between the different compilation modes.


sj
Beginner
428 Views

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)

JesusG_Intel
Moderator
404 Views

Hi SJ,


We are investigating your issue. Please stay tuned.


JesusG_Intel
Moderator
398 Views

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/high....


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


JesusG_Intel
Moderator
397 Views

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. 


sj
Beginner
388 Views

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.

JesusG_Intel
Moderator
380 Views

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.


sj
Beginner
377 Views

Thank you Jesus. I appreciate the efforts.

JesusG_Intel
Moderator
372 Views

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.

 

View solution in original post

Ray1
Beginner
177 Views

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