On Thu, Nov 01, 2018 at 04:22:55PM -0700, Andy Lutomirski wrote: > 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. If we would have a syscall to specify a list fixups that would do the job. Now essentially the only reason we require a vDSO is to implement a single fixup for EENTER. If this fixup stuff makes sense for other parts of the kernel, introducing a vDSO for EENTER means essentially adding ABI to the kernel that might possibly become legacy fast. /Jarkko
