Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
31 Views

Buffer management issues between enclave and untrusted memory

Hi there,
To be honest I'm not sure if this is a valid and predicted behaviour or maybe my implementation and thought-process is wrong. Let me explain.
When there's a need to bring in data from untrusted memory to enclave, I thought I can use an ocall which has a buffer with out directive that will be called from within enclave so after ocall finishes, enclave code will use the provided buffer to move forward with the program.

void ocall_transfer_to_enclave([out, size = buffer_len] unsigned char* transfer_buffer,size_t buffer_len);

But ocall fails for buffers more than 120KB. But I can do it with a different logic. Whenever there's a need to move data from untrusted memory to enclave, design your program steps in a way that you can do it with an ecall which has a buffer with in directive.

public void ecall_transfer_to_enclave([in, size = buffer_len] unsigned char* transfer_buffer, size_t len);

Now I can send a reasonably big buffer to enclave (80MB).

Can someone help understand why I encounter such behavior?

Aref Asvadi
0 Kudos
3 Replies
Highlighted
Employee
31 Views

Hi,

Can you please share your code if possible?? And what is the error you are encountering while running the ocall function when passing the data?? if you could specify the error we can resolve whether it is caused by the enclave or the application.

 

0 Kudos
Highlighted
Employee
31 Views

In an ECALL, when copying a buffer into the enclave, the edger8r generated code allocates a memory buffer inside the enclave to copy the data into - this allocation is done with malloc, then the data is copied. After the called function finishes execution the memory is freed - you can see that in the generated code.

In an OCALL, when copying a buffer out of the enclave, the edger8r generated code allocates a memory buffer outside the enclave with a mechanizm similar to 'alloca' - the memory is allocated on the untrusted stack (sgx_ocalloc), and not with malloc. Stack size is limited, therefore you can't use that for big buffers.

0 Kudos
Highlighted
Beginner
31 Views

Hi Ishai,
Thanks a lot, it makes sense now. But, why not allocating memory from heap for ocall instead of stack? Is this for security reasons? Like for the case that an sgx machine may host a malicious enclave program that can potentially ask for a big chunk of buffer and cause system to crash? Just curious to see what is the underlying security consideration.

Aref Asvadi
0 Kudos