On Fri, Nov 2, 2018 at 7:27 PM Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > On Fri, Nov 02, 2018 at 10:48:38AM -0700, Andy Lutomirski wrote: > > This whole mechanism seems very complicated, and it's not clear > > exactly what behavior user code wants. > > No argument there. That's why I like the approach of dumping the > exception to userspace without trying to do anything intelligent in > the kernel. Userspace can then do whatever it wants AND we don't > have to worry about mucking with stacks. > > One of the hiccups with the VDSO approach is that the enclave may > want to use the untrusted stack, i.e. the stack that has the VDSO's > stack frame. For example, Intel's SDK uses the untrusted stack to > pass parameters for EEXIT, which means an AEX might occur with what > is effectively a bad stack from the VDSO's perspective. What exactly does "uses the untrusted stack to pass parameters for EEXIT" mean? I guess you're saying that the enclave is writing to RSP+[0...some_positive_offset], and the written data needs to be visible to the code outside the enclave afterwards? In other words, the vDSO helper would have to not touch the stack pointer (only using the 128-byte redzone to store spilled data, at least across the enclave entry), and return by decrementing the stack pointer by 8 immediately before returning (storing the return pointer in the redzone)? So you'd call the vDSO helper with a normal "call vdso_helper_address", then the vDSO helper does "add rsp, 8", then the vDSO helper does its magic, and then it returns with "sub rsp, 8" and "ret"? That way you don't touch anything on the high-address side of RSP while still avoiding running into CET problems. (I'm assuming that you can use CET in a process that is hosting SGX enclaves?)
