On 11/8/18 12:05 PM, Andy Lutomirski wrote: > Hmm. The idea being that the SDK preserves RBP but not RSP. That's > not the most terrible thing in the world. But could the SDK live with > something more like my suggestion where the vDSO supplies a normal > function that takes a struct containing registers that are visible to > the enclave? This would make it extremely awkward for the enclave to > use the untrusted stack per se, but it would make it quite easy (I > think) for the untrusted part of the SDK to allocate some extra memory > and just tell the enclave that *that* memory is the stack. I really think the enclave should keep its grubby mitts off the untrusted stack. There are lots of ways to get memory, even with stack-like semantics, that don't involve mucking with the stack itself. I have not heard a good, hard argument for why there is an absolute *need* to store things on the actual untrusted stack. We could quite easily have the untrusted code just promise to allocate a stack-sized virtual area (even derived from the stack rlimit size) and pass that into the enclave for parameter use.
