Is it possible to write a loader program in an enclave

[Fan]

I want to write a loader enclave program that takes a binary string as input and executes it in the same enclave. I guess this breaks down to the following two questions:

1. Is it possible for an enclave program to lift an RW EPC page to an RWX page?
2. Is it possible for to use jump instructions with target addresses within the enclave?

I think the Programming Manual has answered the second question by not listing jmp as an illegal instruction in Table 3-1. However, I'm not sure if the first bullet is possible or not. Also, there might be other restrictions that I'm not aware of.

Any idea?

[Surenthar_S_Intel]

Yes, you can write a loader program within an enclave and you can do both #1 and #2 (the restriction on jumping is that you can’t jump outside the enclave; jumping within it is fine).

[Mark_S_Intel2]

With SGX1 you cannot modify the permissions of an EPC page after it has been EADD'ed.  Using the Intel(R) SGX SDK, the section in the .dll enclave file must be loaded with RWX permission in order to be both writeable and executable.  (In the future, SGX2 with Enclave Dynamic Memory Management will support the modification of page attributes).

Note: Using RWX sections and dynamically loading code into an enclave may create security vulnerabilities.  It should be done with caution.  Section 10 of the Intel(R) SGX Enclave Writer's Guide touches on some of the concerns.

[Fan]

Surenthar S. (Intel) wrote:

Yes, you can write a loader program within an enclave and you can do both #1 and #2 (the restriction on jumping is that you can’t jump outside the enclave; jumping within it is fine).

Great. I revisited the programming manual and figured EMODPE might be the right instruction for doing this. So to follow up, is there corresponding SDK API? Also, as another comment pointed, is this allowed at all in SGX1?

[Fan]

Mark S. (Intel) wrote:

With SGX1 you cannot modify the permissions of an EPC page after it has been EADD'ed.  Using the Intel(R) SGX SDK, the section in the .dll enclave file must be loaded with RWX permission in order to be both writeable and executable.  (In the future, SGX2 with Enclave Dynamic Memory Management will support the modification of page attributes).

Note: Using RWX sections and dynamically loading code into an enclave may create security vulnerabilities.  It should be done with caution.  Section 10 of the Intel(R) SGX Enclave Writer's Guide touches on some of the concerns.

Just to confirm, do you mean that EMODPE is forbidden after an EPC page is EADD'ed? If so, loading the whole .dll as RWX is indeed the only way to do so.

[Mark_S_Intel2]

Fabian N. wrote:

Quote:

Mark S. (Intel) wrote:

With SGX1 you cannot modify the permissions of an EPC page after it has been EADD'ed.  Using the Intel(R) SGX SDK, the section in the .dll enclave file must be loaded with RWX permission in order to be both writeable and executable.  (In the future, SGX2 with Enclave Dynamic Memory Management will support the modification of page attributes).

Note: Using RWX sections and dynamically loading code into an enclave may create security vulnerabilities.  It should be done with caution.  Section 10 of the Intel(R) SGX Enclave Writer's Guide touches on some of the concerns.

Just to confirm, do you mean that EMODPE is forbidden after an EPC page is EADD'ed? If so, loading the whole .dll as RWX is indeed the only way to do so.

EMODPE is an SGX2 instruction.  It is not supported in Intel(R) 6th Generation Core™ Processor based platforms which support SGX1 instructions. 

The whole .dll does not need to be RWX, but only PE sections (or pages) which need both W and then X permission (again, please note the security concerns).

[Fan]

Mark S. (Intel) wrote:

Quote:

Fabian N. wrote:

Quote:

Mark S. (Intel) wrote:

With SGX1 you cannot modify the permissions of an EPC page after it has been EADD'ed.  Using the Intel(R) SGX SDK, the section in the .dll enclave file must be loaded with RWX permission in order to be both writeable and executable.  (In the future, SGX2 with Enclave Dynamic Memory Management will support the modification of page attributes).

Note: Using RWX sections and dynamically loading code into an enclave may create security vulnerabilities.  It should be done with caution.  Section 10 of the Intel(R) SGX Enclave Writer's Guide touches on some of the concerns.

Just to confirm, do you mean that EMODPE is forbidden after an EPC page is EADD'ed? If so, loading the whole .dll as RWX is indeed the only way to do so.

EMODPE is an SGX2 instruction.  It is not supported in Intel(R) 6th Generation Core™ Processor based platforms which support SGX1 instructions. 

The whole .dll does not need to be RWX, but only PE sections (or pages) which need both W and then X permission (again, please note the security concerns).

I see. I think the sgx_create_enclave

loads the enclave DLL:

sgx_status_t sgx_create_enclave(
    const char *file_name,
    const int debug,
    sgx_launch_token_t *launch_token,
    int *launch_token_updated,
    sgx_enclave_id_t *enclave_id,
    sgx_misc_attribute_t *misc_attr
);

Judging from its signature, this API hasn't exposed any control over the permission of the loaded DLL (or any section). Am I missing something? I presume in principle I can write my own DLL loader, but doing that will require some information about the structure of Enclave.dll and I'm not sure whether that information is public. Any suggestion?

[Mark_S_Intel2 · Accepted solution]

Fabian N. wrote:

Quote:

Mark S. (Intel) wrote:

Quote:

Fabian N. wrote:

Quote:

Mark S. (Intel) wrote:

With SGX1 you cannot modify the permissions of an EPC page after it has been EADD'ed.  Using the Intel(R) SGX SDK, the section in the .dll enclave file must be loaded with RWX permission in order to be both writeable and executable.  (In the future, SGX2 with Enclave Dynamic Memory Management will support the modification of page attributes).

Note: Using RWX sections and dynamically loading code into an enclave may create security vulnerabilities.  It should be done with caution.  Section 10 of the Intel(R) SGX Enclave Writer's Guide touches on some of the concerns.

Just to confirm, do you mean that EMODPE is forbidden after an EPC page is EADD'ed? If so, loading the whole .dll as RWX is indeed the only way to do so.

EMODPE is an SGX2 instruction.  It is not supported in Intel(R) 6th Generation Core™ Processor based platforms which support SGX1 instructions. 

The whole .dll does not need to be RWX, but only PE sections (or pages) which need both W and then X permission (again, please note the security concerns).

I see. I think the sgx_create_enclave

loads the enclave DLL:

sgx_status_t sgx_create_enclave(
    const char *file_name,
    const int debug,
    sgx_launch_token_t *launch_token,
    int *launch_token_updated,
    sgx_enclave_id_t *enclave_id,
    sgx_misc_attribute_t *misc_attr
);

Judging from its signature, this API hasn't exposed any control over the permission of the loaded DLL (or any section). Am I missing something? I presume in principle I can write my own DLL loader, but doing that will require some information about the structure of Enclave.dll and I'm not sure whether that information is public. Any suggestion?

The foundation of an enclave .dll file is an initial .dll file (in PE file format) produced by the linker (there are a few considerations in the initial .dll file such as it may not have any imports and should be built with Intel SGX SDK libraries which are configured to run within an enclave).  The signing tool adds special metadata to the file.  This metadata will help sgx_create_enclave() load and configure the enclave .dll. 

If a data section in the initial .dll file is configured for specific permissions, using a method such as a linker script, then sgx_create_enclave() will obey these permissions when it loads the enclave.  There are pitfalls when configuring section permissions (hence, why RWX is not recommended for trusted code).  You should make sure that the permissions, which are done on a page basis, do not spill over into another section which you intend to be less permissive (dumping the .dll file can show you this).