On Wed, Sep 26, 2018 at 2:45 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > On 09/26/2018 02:15 PM, Andy Lutomirski wrote: > > Could we perhaps have a little vDSO entry (or syscall, I suppose) that > > runs an enclave an returns an error code, and rig up the #PF handler > > to check if the error happened in the vDSO entry and fix it up rather > > than sending a signal? > > Yeah, signals suck. > > So, instead of doing the enclave entry instruction (EENTER is it?), the > app would do the vDSO call. It would have some calling convention, like > "set %rax to 0 before entering". Then, we just teach the page fault > handler about the %RIP in the vDSO that can fault and how to move one > instruction later, munge %RIP to a value that tells about the error, > then return from the fault. It would basically be like the kernel > exception tables, but for userspace. Right? Yeah. Maybe like this: xorl %eax,%eax eenter_insn: ENCLU[whatever] eenter_landing_pad: ret And the kernel would use the existing vdso2c vdso-symbol-finding mechanism to do the fixup. > > How would a syscall work, though? I assume we can't just enter the > enclave from ring0. My understanding of how AEX works is a bit vague, but maybe a syscall could reuse the mechanism? The vDSO approach seems considerably simpler. We do need to make sure that a fault that happens on or after return from an AEX event does the right thing. But I'm still vague on how that works, sigh. --Andy
