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.
