Intel® SGX SDK - A request to make OCALLS more seamless for DLL imports

While porting an existing application to run within an enclave environment, it is ideal to keep the changes to source to minimal.  However, existing applications do come with dependencies, the most common and obvious of which is dependency on Win32 APIs.  Projects like Microsoft Haven goes to length to shield an application's execution environment from such direct dependency on untrusted environment by leveraging Microsoft Drawbridge mechanisms like library OS and picoprocess.  However, such extensive changes are neither warranted for a significant number of applications nor feasible even, unless Drawbridge leveraged mechanisms are readily available and out of the box for seamless adoption. 

Most Intel® SGX porting efforts for existing Windows applications are likely to simply adopt Intel® SGX provided feature sets to make the necessary changes to existing source and as appropriate, for it to be functional within an enclave.  And those existing applications are likely to already rely on Win32 APIs at varied levels and thus the porting effort is likely to involve making a sizable number of OCALLs.  Currently, it takes a level of indirection to make such calls.  The source line that makes the Win32 call need to be modified to either accept the win32 API call's return value as a parameter or the function call itself need to be replaced to call to a wrapper function.

It would make for a cleaner porting if the generated code for OCALLs to DLL imports are made more seamless, where the return value from the API is still returned the classic way.  This would imply source level changes are reduced.  Simply extending the EDL file with relevant OCALLs would do.  Of course, error checking and troubleshooting might still force additional changes but with pre-existing, time tested applications that are conducive for Intel® SGX porting and likely to just work with minimal changes, it makes the porting changes look all the more simple!  For SGX related error pertaining to the OCALL, a GetLastError equivalency at Intel® SGX SDK level would work. 

The need for this relatively trivial change is unlikely to be appreciated by those who prefer Intel® SGX to be used in its intended way, with minimal and selective code running within the enclave environment.  But, this change is more useful when a significant portion of existing source is moved nearly en masse to work as an enclave application/library and that appears to be pretty much the case when porting existing libraries.

Also, this modification/addition will reduce the amount of source code changes necessary and make merging of changes to open source applications less clumsy.  From Intel's perspective, it will make Intel® SGX porting appear more effortless and even more simple!

While creating an Intel® SGX enclave, an EDL file (Enclave Definition Language file) is used to describe an enclave's trusted and untrusted functions and types.  These functions are the interface for communication between the enclave and the untrusted application.  The EDL file is read by Edger8r tool provided by the Intel® SGX SDK to generate edge/wrapper routines, which makes relevant checks and copies that ought to happen prior to and after trusted and untrusted calls.

We would like to make a request to Intel® SGX SDK team to add a minor feature to their Edger8r tool to generate prolog and epilog logging to the generated edge routines.  This would obviously be for troubleshooting convenience and in debug environment.  This request is the equivalency of what Microsoft Visual Studio compiler already provides via /Gh (Enable _penter Hook Function) compiler option.

By making it easier to troubleshoot a potentially targeted area, it is true that we might inadvertently encourage more additions to that area, thus rendering it more vulnerable.  However, those being frivolous with the interface functions are unlikely to be conservative because of lack of convenience/features of this nature.  Thus we might as well make it easy for those with a need.  After all, it is requested/recommended for development environment only.

Currently, we can workaround the lack of such a feature by simply adding another layer of indirection to EDL function calls or we could fallback on Microsoft compiler provided _penter hook for the Edger8r generated files.  The former adds an unnecessary layer of indirection while the latter is transient with the Edger8r tool regenerating the files in question for every recompilation.  An addition to Edger8r tool to add prolog/epilog hook, ought to be simple enough while helping troubleshoot problems in this area all the more easier!