Previously, if the enclave was interrupted by a sync signal (e.g.,
SIGILL) or an async signal (e.g., SIGTERM), then the untrusted-runtime
signal handler injected the signal directly into the enclave. In
particular, untrusted runtime ran in the signal-handling context and
called `sgx_raise()` that would perform EENTER to enter the in-enclave
stage-1 signal handler, then EEXIT to exit the enclave back into the
untrusted-runtime signal-handling context, and then untrusted runtime
would perform sigreturn to go back to untrusted-runtime regular context,
jumping to AEP (Asynchronous Exit Pointer). In AEP, ERESUME was called
to resume the enclave execution from the stage-2 signal handler.
In other words, the following invariants held:
- In-enclave stage-1 signal handler (in SSA 1) always executed in the
signal-handling context of the untrusted runtime.
- In-enclave stage-2 signal handler (in SSA 0) always executed in
regular context of the untrusted runtime.
As a preparation for AEX-Notify support, this commit breaks the above
strong coupling of contexts: in-enclave stage-1 signal handler must
execute in regular context of the untrusted runtime.
In particular, this commit changes signal-handling logic as follows:
instead of immediately delivering a sync/async signal into the enclave,
the untrusted runtime's signal handler memorizes the signal in a
thread-local variable `last_sync_signal`/`last_async_signal` and
returns. When host kernel returns back to regular context from the
signal handler, it jumps to the AEP, which is augmented with a new
logic: checking whether there is any signal pending (variables
`last_sync_signal` or `last_async_signal` are not zero). If there is a
pending signal, the new AEP logic performs EENTER, so that in-enclave
stage-1 handler executes. After the stage-1 handler is done, it performs
EEXIT, and the AEP logic finalizes with ERESUME as usual. At this point
the flow is the same as was previously implemented: the enclave is
resumed in the in-enclave stage-2 handler.
There is one corner case: an async signal can arrive while the enclave
is executing the stage-1 handler (in SSA 1). In this case, an async
signal flow is triggered in untrusted runtime, and the AEP after the
async signal will try to EENTER, but since there's already SSA 1
executing inside the enclave and SSA 2 is forbidden by SGX hardware,
this (nested) EENTER will raise a #GP fault which translates into
SIGSEGV and is delivered to the untrusted runtime's signal handler. We
augment the SIGSEGV (aka PAL_EVENT_MEMFAULT) signal handler to catch
this particular case and ignore it: the async signal is re-memorized in
`last_async_signal` variable but cannot be delivered right now. This
async signal will be delivered on some later AEX event.
Signed-off-by: Dmitrii Kuvaiskii <[email protected]>