Enable gdb plugin to work with enclave from buffer#902
Enable gdb plugin to work with enclave from buffer#902gilanghamidy wants to merge 1 commit intointel:mainfrom
Conversation
gilanghamidy
force-pushed
the
dev/enclave_buffer_debug
branch
from
790672c to
ea857f3
Compare
|
|
||
| # dump enclave to file | ||
| dump_name = "/tmp/enclave_dump_{0}.bin".format(time.time()) | ||
| buffer_ptr = gdb.parse_and_eval("$rsi") |
There was a problem hiding this comment.
The code assumes we are under 64-bit. Currently we still need to support 32-bit so we may need to add that support as well just like we do for several other internal breakpoints
There was a problem hiding this comment.
Hey, thank you for your review. Indeed I was thinking the same thing about the support for 32-bit as the SDK and SGX is also support 32-bit system. However, I am not sure how to test that since I am running the 64-bit system. I assume I will need to do either cross-compiling or install a 32-bit VM. Perhaps the difference is that the debugger now needs to inspect the stack as the function parameter is now spilled to the stack instead of register. But I guess we can do that. I'll see if I can help in the coming days :)
| # This breakpoint is to handle enclave creation with buffer | ||
| class CreateBufferEnclaveBreakpoint(gdb.Breakpoint): | ||
| def __init__(self): | ||
| gdb.Breakpoint.__init__ (self, spec="_create_enclave_from_buffer_ex", internal=1) |
There was a problem hiding this comment.
As you mentioned in PR description, we rely on the existence of this symbol _create_enclave_from_buffer_ex. I think this may not be a problem because if the user is actually doing the debugging, s/he needs to install the libsgx-urts-dbgsym package anyway, and the symbols will be there.
xxu36
left a comment
xxu36
left a comment
There was a problem hiding this comment.
The general idea looks good to me, thanks for the contribution :)
- Initially, the gdb requires the enclave file to load the symbol. However, if we create the enclave from `sgx_create_enclave_from_buffer_ex`, the file information is not populated by the URTS, which prevents the gdb plugin to load the symbols - This patch allows the gdb plugin to hook into the `_create_enclave_from_buffer_ex` function and perform necessary patching to allow enclave not from file to be debugged Signed-off-by: Gilang Mentari Hamidy <gilang.hamidy@kuleuven.be>
gilanghamidy
force-pushed
the
dev/enclave_buffer_debug
branch
from
ea857f3 to
a06b8b4
Compare
2 participants
sgx_create_enclave_from_buffer_ex, the file information is not populated by the URTS, which prevents the gdb plugin to load the symbols_create_enclave_from_buffer_exfunction and perform necessary patching to allow the enclave not created from file to be debuggedThis fixes the long-running issue of #482
The signature of the entry function:
The idea is that the debugger internally stops in the entry point of
_create_enclave_from_buffer_excheck thefileparameter if thefile.nameisnullptr(pointer tofileis stored in$ecx). If so, we create a temporary file in the/tmpdirectory, and dump the enclave buffer on thebase_addr($rsi). Then, we replace thefile.namevalue fromnullptrinto a dynamically-allocated string that contains the path to the temporary file. During the breakpoint, we callmallocfrom gdb to obtain the dynamically-allocated buffer to store the string so that it can be stored in the normal way by the URTS.The debugger also keeps track over the temporary buffer file and malloc-ed pointer, which after the enclave is destroyed and
fini_enclave_debugis called, it deletes the temporary buffer file and the malloc-ed pointer by callingfree.In this way, no changes at all are required to the internal URTS, PSW, and API compatibility. However, it may only work as long as the
_create_enclave_from_buffer_exis present in the symbol table. I tested it using the normal build (non-debug PSW), and it looks like the compiler retains the local symbol so it can still be captured by the breakpoint.