When an enclave writer develops a 32-bit enclave, the developer must be aware that the enclave may be loaded into a large address (defined here as an address greater than 2GB) or it may receive a pointer from a large address range. The enclave should be designed to cope with these scenarios and fail smartly.
32-bit applications are usually loaded by Windows OS and run below a virtual address of 2 GB. This means that an application developer could expect that the most significant bit in a valid pointer to be zero; and therefore perform a signed operation (subtraction, comparison, etc.) on that pointer without impacting the result. If that pointer were allowed to be greater than 2 GB, then the most significant bit would become the sign bit on a signed operation and the result of the operation may change. For example, the program flow for the code below would change based on whether the enclave is loaded to an address greater than 2GB. Because ptr1 and ptr2 point inside the enclave, they would become negative numbers.
Since the enclave itself cannot control whether the system is configured to support large addresses for 32-bit programs and the enclave cannot control where it is loaded or the inputs it receives, all 32-bit enclaves should expect that they can be loaded above the 2 GB limit or receive a pointer that references memory above this limit.
int * ptr1, ptr2;
// Perform some operation that initializes ptr1 and ptr2 to be inside the enclave
if ( (LONG_PTR)ptr1 > (LONG_PTR)ptr2 ) //Note: LONG_PTR is signed
//do something else
The developer must also be aware that pointers may be subject to integer conversion rules when used in any arithmetic or comparison operation. These rules may convert a large address into a negative number and influence the outcome of the operation; thereby potentially impacting the integrity of the security solution.
This is similar to preparing a 32-bit application to use the /LARGEADDRESSAWARE linker option in the Microsoft linker.