On Tue, 2018-11-06 at 08:57 -0800, Andy Lutomirski wrote: > > So I guess the non-enclave code basically can’t trust its stack pointer > because of these shenanigans. And the AEP code has to live with the fact > that its RSP is basically arbitrary and probably can’t even be unwound > by a debugger? The SDK provides a Python GDB plugin to hook into the out-call flow and do more stack shenanigans. From what I can tell it's fudging the stack to make it look like a normal stack frame so the debugger can do it's thing. > And the EENTER code has to deal with the fact that its red zone can be > blatantly violated by the enclave? That's my understanding of things. So yeah, if it wasn't obvious before, the trusted and untrusted parts of the SDK are very tightly coupled.
