Intel® Software Guard Extensions (Intel® SGX)
Discussion board focused on hardware-based isolation and memory encryption to provide extended code protection in solutions.

Maybe inconsistence in SGX documentation

Joe63
Beginner
1,556 Views

Hey,

i think i have spotted a inconsistence in the two SGX papers.

 

 

 

  • In the first documentation there is stated in "Inputs Passed by Reference" that only the reference is copied to the enclave and i have to check if the reference references doesnt reference to enclave memory.
  • In the second documentation is stated in "Pointer Handling" that the buffer pointed by will be copied if the direction attributes in the edl file are correct and also the edge routine checks if the reference is outside the enclave memory (ECall).

Which argument is right? :)

 

First docu: https://download.01.org/intel-sgx/linux-1.7/docs/Intel_SGX_Developer_Guide.pdf

Second docu: https://download.01.org/intel-sgx/linux-1.7/docs/Intel_SGX_SDK_Developer_Reference_Linux_1.7_Open_Source.pdf

0 Kudos
1 Solution
AArya2
New Contributor I
1,556 Views

The first document (Intel SGX Developer Guide) is more low level than the second (SGX SDK Developer Reference).

As far as the CPU is concerned, a pointer passed to an enclave in an ECALL can point to anywhere in memory. Therefore it is upon the enclave itself to check if the referenced buffer resides outside or inside enclave memory.

The SDK however, provides this functionality for us. What edgr8r does, is to spit out code inside the enclave to performs such checks.

So it IS upon the enclave to do memory range checks. However, those parts of the enclave code are automatically produced by edger8r (a component of the SDK). That's why you, as a developer using the SDK don't need to worry about it.

View solution in original post

0 Kudos
7 Replies
Surenthar_S_Intel
1,556 Views

Thanks for your Query. We will update you soon.

-Surenthar

0 Kudos
AArya2
New Contributor I
1,557 Views

The first document (Intel SGX Developer Guide) is more low level than the second (SGX SDK Developer Reference).

As far as the CPU is concerned, a pointer passed to an enclave in an ECALL can point to anywhere in memory. Therefore it is upon the enclave itself to check if the referenced buffer resides outside or inside enclave memory.

The SDK however, provides this functionality for us. What edgr8r does, is to spit out code inside the enclave to performs such checks.

So it IS upon the enclave to do memory range checks. However, those parts of the enclave code are automatically produced by edger8r (a component of the SDK). That's why you, as a developer using the SDK don't need to worry about it.

0 Kudos
Joe63
Beginner
1,556 Views

Arya Pourtabatabaie wrote:

The first document (Intel SGX Developer Guide) is more low level than the second (SGX SDK Developer Reference).

As far as the CPU is concerned, a pointer passed to an enclave in an ECALL can point to anywhere in memory. Therefore it is upon the enclave itself to check if the referenced buffer resides outside or inside enclave memory.

The SDK however, provides this functionality for us. What edgr8r does, is to spit out code inside the enclave to performs such checks.

So it IS upon the enclave to do memory range checks. However, those parts of the enclave code are automatically produced by edger8r (a component of the SDK). That's why you, as a developer using the SDK don't need to worry about it.

 

Okay, thanks for that suitable answer.

Can i use a (e.g. ECall) without using the edger8r? Or is every ECall which is defined in the .edl File automatically a edger8r-supported call (with embedded pointer checks)? I know from the manual that the edger8r has to be enabled but i wonder if there is a alternative (Without alternatives to the edger8r the low-level-description you mentioned above wouldnt have a need because i have to use the edger8r anyway).

0 Kudos
AArya2
New Contributor I
1,556 Views

I personally haven't tried writing ECALLs without edger8r in the loop and wouldn't advise it because it's tedious, difficult and error-prone to write edge routines manually.

But if you want to check the integrity of some of the referenced buffers yourself, you can specify the input pointer's type with [user_check].

Example:

public my_ecall ([in, count = d_len] uint8_t *d, uint32_t d_len, [user_check] uint8_t *my_buffer);

Using this description, whenever my_ecall is called from outside the enclave, the edge function copies the buffer d[0] ... d[d_len-1] (from the host app's perspective) into enclave memory, and passes a pointer to THE NEW BUFFER to the enclave function as 'd'.

But the edge function doesn't do anything to my_buffer and passes its value untouched, as if it's not a pointer at all.

0 Kudos
Juan_d_Intel
Employee
1,556 Views

It is possible to ECALL into the enclave without using the sgx_edger8r. However, as Arya pointed out, it is error-prone.

If you want to check the buffers inside the enclave, I'd recommend you follow Arya's suggestion and use [user_check].

0 Kudos
Joe63
Beginner
1,556 Views

Juan D. (Intel) wrote:

It is possible to ECALL into the enclave without using the sgx_edger8r. However, as Arya pointed out, it is error-prone.

If you want to check the buffers inside the enclave, I'd recommend you follow Arya's suggestion and use [user_check].

Okay thanks, one additional question:

The user_check stuff is only possible and needed for values with reference. So as you mentioned, the user_check macro advices SGX to not do this checks for pointers. These checks are size-check, type-check and copy of the pointing buffer to enclave memory.

My question is: How is it with parameters which are not a pointer (paramaters like int).  For that parameters i dont have the user_check macro. As I understand the manual, the checks (type size and copy) are realizes for that parameters always, so i cant disable that checks for no pointer parameters (like int) right?

0 Kudos
Juan_d_Intel
Employee
1,556 Views

Non-pointer parameters like int are copied from the untrusted domain into the enclave when the trusted bridge references the parameter at the ECALL function call site. The marshaling routines can't do any additional checking. The enclave may do additional checking if these parameters have specific bounds (determined by the application design).

0 Kudos
Reply