On 2020-08-22 23:55, Andy Lutomirski wrote: > On Thu, Aug 20, 2020 at 10:53 AM Jethro Beekman <jethro@xxxxxxxxxxxx> wrote: >> >> On 2020-08-20 19:44, Andy Lutomirski wrote: >>> This is a genuine semantic question: is __vdso_sgx_enter_enclave() >>> like read on a pipe (returns -EINTR on a signal) or is it more like a >>> restartable syscall or a normal library function that just keeps >>> running if your signal handler does nothing? You could siglongjmp() >>> out, but that's a bit gross. >>> >>> I wouldn't object to an option to __vdso_sgx_enter_enclave() to make >>> it return -EINTR if signaled by a non-SA_RESTART signal. Implementing >>> it might be distinctly nontrivial, though. >>> >>> But this isn't what this patch does, and I suspect we've been talking >>> past each other. This patch makes __vdso_sgx_enter_enclave() return >>> if there's an *interrupt*. If you push a keyboard button, move your >>> mouse, get a network interrupt on that core, etc, it will return. >>> This is nonsense. >> >> It's not nontrivial to return on signals, this patch does it. This patch *also* returns when there's a HW interrupt, but that's not important. > > Allow me to quote the changelog of the patch: > > This allows the user's runtime to switch > contexts at opportune times without additional overhead, e.g. when using > an M:N threading model (where M user threads run N TCSs, with N > M). > > NAK. > >> >> It sounds like you're saying you want to subdivide AEXs into “interrupts that lead to user-observable signals” and “other interrupts”, and then hide the second category from the user. I wouldn't object to that, but I don't know how to code this. It seems like a lot of work compared to the obvious solution (this patch). > > The obvious solution is NAKked. > > Does siglongjmp() really not work for you? Allow me to quote the changelog of "[PATCH v36 18/24] x86/vdso: Add support for exception fixup in vDSO functions": Putting everything together, userspace enclaves will utilize a library that must be prepared to handle any and (almost) all exceptions any time at least one thread may be executing in an enclave. Leveraging signals to handle the enclave exceptions is unpleasant, to put it mildly, e.g. the SGX library must constantly (un)register its signal handler based on whether or not at least one thread is executing in an enclave, and filter and forward exceptions that aren't related to its enclaves. This becomes particularly nasty when using multiple levels of libraries that register signal handlers, e.g. running an enclave via cgo inside of the Go runtime. If I could use signal handlers I wouldn't use the VDSO call. (Corollary: if I wasn't using the VDSO call, I wouldn't have to think about this because what I want is already supported). -- Jethro Beekman | Fortanix
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
