On Thu, Nov 1, 2018 at 2:24 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Nov 1, 2018 at 12:31 PM Rich Felker <dalias@xxxxxxxx> wrote: > > > > See my other emails in this thread. You would register the *address* > > (in TLS) of a function pointer object pointing to the handler, rather > > than the function address of the handler. Then switching handler is > > just a single store in userspace, no syscalls involved. > > Yes. > > And for just EENTER, maybe that's the right model. > > If we want to generalize it to other thread-synchronous faults, it > needs way more information and a list of handlers, but if we limit the > thing to _only_ EENTER getting an SGX fault, then a single "this is > the fault handler" address is probably the right thing to do. It sounds like you're saying that the kernel should know, *before* running any user fixup code, whether the fault in question is one that wants a fixup. Sounds reasonable. I think it would be nice, but not absolutely necessary, if user code didn't need to poke some value into TLS each time it ran a function that had a fixup. With the poke-into-TLS approach, it looks a lot like rseq, and rseq doesn't nest very nicely. I think we really want this mechanism to Just Work. So we could maybe have a syscall that associates a list of fixups with a given range of text addresses. We might want the kernel to automatically zap the fixups when the text in question is unmapped.
