On Thu, Nov 08, 2018 at 12:10:30PM -0800, Dave Hansen wrote: > 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. Convenience and performance are the only arguments I've heard, e.g. so that allocating memory doesn't require an extra EEXIT->EENTER round trip. > 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. I agree more and more the further I dig. AFAIK there is no need to for the enclave to actually load %rsp. The initial EENTER can pass in the base/top of the pseudo-stack and from there the enclave can manage it purely in software.
