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!
0 Comments
Leave a Reply. |
AuthorFounder of KryptoGuard™ technology initiative, product and services. Archives
June 2021
Categories |