Add user exception handling.

[kongoshuu]

Add user exception handling.

Allow user exception (like signal handler) to be handled by an ecall.

[yuyuany]

If you want to handle an exception inside the enclave, it's recommended to use SGX exception handling APIs. Instead of using an ECALL, you can register the exception handler within the enclave by sgx_register_exception_handler. So tRTS will call your registered handler when exception occurs.
When an ECALL enters with cssa = 1, tRTS switches the stack to the designated space, whose size is limited. It is not safe to call an user exception handling in such environment.

[kongoshuu]

We are trying to handle not only hardware exceptions, but also other software/user defined signals, including SIGCHLD, SIGUSR1, SIGRTMIN + n, etc. And it seems this approach works better for us. We are aware of the stack size problem, and I opened another PR to increase the STATIC_STACK_SIZE. This is a temporary solution for now though, we'll add another more stable and flexible solution to the stack size.

[ghost]

We can achieve the goal by extend the existing framework to support SIGCHLD, SIGUSR1, SIGRTMIN + n, etc. increase the STATIC_STACK_SIZE is not a solution.

[yuyuany]

--- a/sdk/trts/trts_veh.cpp
+++ b/sdk/trts/trts_veh.cpp
@@ -388,11 +388,6 @@ extern "C" sgx_status_t trts_handle_exception(void *tcs)
         }
     }

-    if(ssa_gpr->exit_info.valid != 1)
-    {   // exception handlers are not allowed to call in a non-exception state
-        goto default_handler;
-    }
-

[yuyuany]

Does the tRTS exception handling meets your requirement, if you make the above changes?

[ghost]

Remove if(ssa_gpr->exit_info.valid != 1), at the meantime uRTS needs to deliver SIGCHLD, SIGUSR1, SIGRTMIN + n to the tRTS exception handler.

[yuyuany]

Yes, signals will be passed to user's exception handler. Do you need any other information, such as siginfo, context, ect. Some information caught from outside the enclave is incorrect. We provided exception_info_t structure and passed the register state to the exception handler. Is it enough for you?

[kongoshuu]

Thank you for looking into this. This is probably not going to help our case though. We need to register handlers which needs to know the signal info, including signal number, and exception_info_t does not seem to provide that (context will be needed also).

[haitaohuang]

@kongoshuu could you provide some sample code to clarify how you intend to use this feature?