Community
cancel
Showing results for 
Search instead for 
Did you mean: 
tz71
Beginner
106 Views

Problem using "IO" operations as ocalls inside enclave

Jump to solution

I wrote an untrusted IO interface including IO operations like read/write from/to a file as ocalls to use them inside my enclave, but none of the operations works! I thought it is possible to do IO instructions inside enclaves by making ocalls Is there any thing else that I should do?
The bellow is a sample code of what I'm doing.

//ocall write function in the untrusted part of the app
void ocall_file_write(const char* path, char* s, long long n,long long *current_pos){
	 fstream myfile(path,ios::out | ios::binary|ios::ios_base::app);
	  ...
	  myfile.write((s),(streamsize)n);
	  ...
	  myfile.close();
}

//ecall write inside the enclave
void ecall_file_write(){
//initialize the parameters
ocall_file_write(....)
}

//the edl file
trusted{
public void ecall_file_write(void);
}
untrusted{
void ocall_file_write([in]const char* path,[in]long long* current_pos,[in] const char* s, long long n );
}

 

0 Kudos
1 Solution
106 Views

Hi Zahra,

Syscall instruction is prohibited inside the enclave. The OS is not a part of the trusted computing base(TCB) in SGX. Lets assume that syscall was enabled inside the enclave and you write instructions in assembly to execute the syscall instruction(lets say with parameters for the open system call sys_open). When you do a syscall you jump to the predefined location setup by the kernel during boot to start executing kernel code. What this means is you are jumping from code written by you(Enclave, which is trusted) to code which is not written by you(OS, which is untrusted). If you were able to do this, it would defeat the security guarantees provided by SGX. Since the kernel/OS/any other software not written by you is untrusted, you could have a malicious kernel whose open system call reads data inside your enclave and steal your secrets.

Workaround:
SGX includes instructions to let you temporarily exit the enclave in order to call untrusted code so that you can perform I/O, make general system calls, etc. and then return to the enclave. This imposes a performance penalty, and you are executing untrusted code during this time (which is not protected by SGX), so this should only be done when necessary and the amount of time spent outside the enclave should be minimized.

Refer page no 229 and Table 20 Unsupported C++ Standard Classes and Functions in Intel-SGX-SDK-Users-Guide-for-Windows-OS.pdf

Thanks and Regards,
Surenthar Selvaraj

View solution in original post

4 Replies
tz71
Beginner
106 Views

I couldn't edit my post. The untrusted part of the "edl" file is like the bellow code (I checked the size of each array).

untrusted{

    void ocall_file_write([in,size=s1]const char* path
                                        ,[in,size=s2]long long* current_pos
                                        ,[in,size=s3] const char* s
                                        ,long long n,size_t s1,size_t s2, size_t s3 );

}

 

107 Views

Hi Zahra,

Syscall instruction is prohibited inside the enclave. The OS is not a part of the trusted computing base(TCB) in SGX. Lets assume that syscall was enabled inside the enclave and you write instructions in assembly to execute the syscall instruction(lets say with parameters for the open system call sys_open). When you do a syscall you jump to the predefined location setup by the kernel during boot to start executing kernel code. What this means is you are jumping from code written by you(Enclave, which is trusted) to code which is not written by you(OS, which is untrusted). If you were able to do this, it would defeat the security guarantees provided by SGX. Since the kernel/OS/any other software not written by you is untrusted, you could have a malicious kernel whose open system call reads data inside your enclave and steal your secrets.

Workaround:
SGX includes instructions to let you temporarily exit the enclave in order to call untrusted code so that you can perform I/O, make general system calls, etc. and then return to the enclave. This imposes a performance penalty, and you are executing untrusted code during this time (which is not protected by SGX), so this should only be done when necessary and the amount of time spent outside the enclave should be minimized.

Refer page no 229 and Table 20 Unsupported C++ Standard Classes and Functions in Intel-SGX-SDK-Users-Guide-for-Windows-OS.pdf

Thanks and Regards,
Surenthar Selvaraj

View solution in original post

tz71
Beginner
106 Views

Hi Surenthar,

Actually I found the bug of my code. There is no problem having File Operations by making ocalls.

Thanks

106 Views

Thanks for your update.

Reply