Openenclave: Exception and Signal handling for SGX in OE SDK

[radhikaj]

Opening this issue as a result of an action item from SIG-Arch.
The purpose of this issue is to identify any improvements that can be made in OE SDK in the area of signal and exception handling for SGX.
@mwshan, @anakrish, Please add any gaps between OE SDK and Intel SDK in the areas of exception and signal handling for SGX to this issue.

[dthaler]

Is this issue really SGX specific?

[MWShan]

A draft description of the Intel SGX SDK exception handling flow is posted here: SGX Exception Handling - Linux. This document references a whitepaper which gives a description of basic exception handling in SGX. The whitepaper can be downloaded here: Exception Handling in Intel® Software Guard Extensions (Intel® SGX) Applications.

The exception handling support including SW flows is very similar between the two SDKs.

Some of the differences between the two implementations are:

• Interface/Types: OE uses oe_add_vectored_exception_handler instead of sgx_register_exception_handler

  • The user written handler function uses oe_exception_record_t instead of sgx_exception_info_t
    
    
    
    • oe_exception_record_t contains a few extra fields, x87 and SSE values, and is missing RFLAGS (not sure if this will impact)
    
    
    • oe_exception_record_t uses abstracted exception vectors where sgx_exception_info_t uses the vectors provided in SGX architecture
    
    
  • Error codes are different…

• Intel SGX SDK stores the handler addresses as address^random_number – this makes it more difficult for an adversary to configure an address in the table.

[radhikaj]

2648 also relates to the same area.

[anakrish]

Here is my In Progress documentation that is based on @MWShan 's documents; but written more as a documentation of OE SDK exception handling
https://github.com/anakrish/openenclave/blob/ak_docs/docs/SgxExceptionHandling.md

One thing to cover for both SDK's is a description of the exception safety semantics for registered handlers: #2648
There are some nuances around PLT/Incremental linking, ptrace/debuggers, abstracting windows/linux implementations, and FS/GS in first-pass/second pass exception handlers, that I'm planning to document/provide and overview.

[nonpolarity]

@MWShan Thanks for your information!
Just one more question, is there some doc to elaborate this table?
it is from Exception Handling in Intel® Software Guard Extensions (Intel® SGX) Applications.

[CodeMonkeyLeet]

Per SIG-Arch meeting, this issue doesn't need discussion in the SIG-Arch forum yet. @MWShan will address the questions raised by @anakrish and bring and outstanding issues back to SIG-Arch for discussion as needed.

[MWShan]

The above table is provided in Volume 3D of the Intel(R) 64 and IA-32 Architectures Software Developer's Manual see Table 37-11 in section 37.9.1.2 "VECTOR Field Definition"

The latest table also includes the #CP Control protection exception which is used in Control Flow Enforcement Technology.