Reading EXITINFO?

[Fan]

Hi,

I'm trying to read EXITINFO from SSA to detect whether the current thread has been interrupted in the past. But I don't have enough information to locate the current SSA in the memory. Can you guys shed some light on where to start?

Fan

[Mark_S_Intel2]

If you register an exception handler using sgx_register_exception_handler( ), then your exception handler will be called with a sgx_exception_info_t structure. 

The info->exception_type and info->exception_vector will define the type and vector from EXITINFO.

Note: your exception handler will not be called if you reenter the enclave after an interrupt or an exception that is not recorded in EXITINFO.

[Fan]

That's exactly what I've been looking for.

Just one thing: If I understand correctly, this handler will be called by ERESUME, when reenter the enclave after an interrupt or an exception. But ERESUME is called by untrusted application. Can the untrusted application bypass the exception handlers somehow?

Fan

[Fan]

Mark S. (Intel) wrote:

If you register an exception handler using sgx_register_exception_handler( ), then your exception handler will be called with a sgx_exception_info_t structure. 

The info->exception_type and info->exception_vector will define the type and vector from EXITINFO.

Note: your exception handler will not be called if you reenter the enclave after an interrupt or an exception that is not recorded in EXITINFO.

First, a quick question: will page fault be reported? 

Second, come to think of it I'm wondering how is this "enclave exception handler" mechanism realized. If I understand correctly, when an AEX happens, firstly a system exception handler will be called. Afterward, the AEP will be called (by pointing RIP to AEP), which will eventually call ERESUME to reenter the enclave. But, my question is which TCS is passed to ERESUME.

If the interrupted TCS is passed, then execution will continue from wherever it's left without going to the enclave exception handler. So a different TCS (with OEntry pointed to the enclave exception handlers) must be used. But it is the untrusted application that controls how ERESUME is called. So it seems like enclave exception handlers can be completely bypassed by the untrusted application, no?

[Surenthar_S_Intel · Accepted solution]

Hi FAN,
Page fault is reported in SGX.
Enclave Exception Handler Mechanism:
Handling Exception:
Asynchronous Exit (AEX) is used to handle the exception in SGX
Faults, exceptions and interrupts initiate the Asynchronous Exit flow.
During AEX, enclave register state is stored in the enclave’s active SSA frame and initialized to a known value prior to leaving the enclave.
The RIP is initialized to an area referred to as the trampoline code

Resuming From Exceptions:
On an AEX the RIP is modified to point to the Trampoline area in the untrusted section of the app. This RIP is pushed onto the stack when jumping to the OS handler.
IRET will return the flow control to the app at the Trampoline Area.
The Trampoline will execute the ERESUME instruction. Register state will be restored from the SSA and Execution will resume from the interrupted location.

TCS can define multiple SSA frames on the SSA stack. AEX pushes content onto the SSA frame and increments the SSA frame
pointer. Last SSA frame state store in TCS will execute, once the ERESUME called.

Please find the attachment for your reference for more info on Handling Exceptionflow in SGX

[Fan]

Surenthar Selvaraj. (Intel) wrote:

Hi FAN,
Page fault is reported in SGX.
Enclave Exception Handler Mechanism:
Handling Exception:
Asynchronous Exit (AEX) is used to handle the exception in SGX
Faults, exceptions and interrupts initiate the Asynchronous Exit flow.
During AEX, enclave register state is stored in the enclave’s active SSA frame and initialized to a known value prior to leaving the enclave.
The RIP is initialized to an area referred to as the trampoline code

Resuming From Exceptions:
On an AEX the RIP is modified to point to the Trampoline area in the untrusted section of the app. This RIP is pushed onto the stack when jumping to the OS handler.
IRET will return the flow control to the app at the Trampoline Area.
The Trampoline will execute the ERESUME instruction. Register state will be restored from the SSA and Execution will resume from the interrupted location.

TCS can define multiple SSA frames on the SSA stack. AEX pushes content onto the SSA frame and increments the SSA frame
pointer. Last SSA frame state store in TCS will execute, once the ERESUME called.

Please find the attachment for your reference for more info on Handling Exceptionflow in SGX

Thanks! Two comments:

1) On my laptop, MISC region is not supported, which means SECS.MISCSELECT.EXINFO=0. Will page fault still be reported?

2) all you said about exception flow makes sense, but you didn't mention when and how the handlers registered by enclaves are called. Can you say more on that?

[Juan_d_Intel]

No, no page fault will the reported. Your laptop will only report exceptions described in the VECTOR Field Definition.

In addition to the flow explained above, the sgx_urts.dll installs an exception handler before ECALLing into the enclave. If an exception happens while running within the enclave, the OS will search for registered exception handlers and will find what sgx_urts.dll has registered. When the sgx_urts.dll's handler gets control, ECALLs into the enclave again to execute the trusted exception handler. The enclave's handler access the information stored in the SSA and gives control to any exception handler the enclave might have registered. If the enclave handles the exception (EXCEPTION_CONTINUE_EXECUTION), sgx_urts.dll returns the same code to the OS, which then ERESUMEs and execution continues inside the enclave at the point where the exception (AEX) occurred. If the enclave doesn't handle the exception (EXCEPTION_EXECUTE_HANDLER) the OS will continue searching up the stack for a handler and eventually will abort the application if no other is found.

[Irene__GP]

Fabian N. wrote:

That's exactly what I've been looking for.

Just one thing: If I understand correctly, this handler will be called by ERESUME, when reenter the enclave after an interrupt or an exception. But ERESUME is called by untrusted application. Can the untrusted application bypass the exception handlers somehow?

Fan

Hi Fan, I have the same concern, since in general enclave program relies on (untrusted) OS to initialize the exception handling routines, isn't possible that malicious OS can re-direct the execution flow for some malicious purpose?

On the other hand, it seems not possible for OS to directly steal secrets since registers within an Enclave has been "scrubbed" before AEX. 

Please let me know if it makes sense to you, thanks.