On 2020-08-26 20:32, Sean Christopherson wrote: > On Mon, Aug 24, 2020 at 03:36:29PM +0200, Jethro Beekman wrote: >> 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, I think what you're requesting is simply not possible. Or rather, > the SGX vDSO can't provide any additional value relative to what can be > provided by userspace. > > What Andy is saying is that having the vDSO take action on interrupts is > undesirable/NAK'd from a kernel perspective, as it's ugly and unreliable. > It happens to mostly work for SIGALRM because there is an interrupt > associated with the expiration of the timer[*]. But even then it will > work if and only if the interrupt arrives while the enclave is running. > If the interrupt arrives just before ENCLU, either on initial entry or > on resume from the callback, SIGALRM will be delivered and the userspace > M:N scheduler that is relying on an exit from the enclave will miss its > "tick". > > The vDSO could check for pending signals, but that effectively provides no > value as opposed to checking for signals in the callback (or caller). > > The goal of the SGX vDSO is to obviate the need for handling signals that > are due to exceptions that are directly associated with the enclave. IMO, > the SIGALRM request is completely out of scope as it is not a problem that > is unique to SGX, i.e. wanting to do M:N scheduling in a library without > hooking SIGALRM is a generic request. The fact that the SGX architcture has > a quirk that allows for a semi-functional hack is not justification for > supporting such a hack in the kernel. > > [*] Is it even guaranteed that an interrupt will precede SIGALRM? Not that > it matters for this discussion. > Let's make sure the VDSO call has a flags parameter and we can talk about this after merge. -- Jethro Beekman | Fortanix
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
