On 8/26/2020 11:32 AM, 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.
Hi Jethro,
I'm with Andy and Sean that it's unprecedented and undesired to notify
applications of interrupts from the kernel's perspective.
I think what you really want is to be notified on signals without a
signal handler, in an effort to avoid conflicts between libraries and
their user applications. But please keep in mind that regarding signals,
there are always 2 parts - signaling and handling. Even though you could
avoid conflicts in the handling, you still may not avoid conflicts in
the signaling part. For example, say you want SIGALRM every 100ms for
M:N scheduling in a lib but the user application also uses SIGALRM for
something else. Even though you can avoid conflict by not registering a
SIGALRM handler, the user application may use SIGALRM at a different
frequency. Hence the lib and the application will still interfere with
each other. Then what's the good of not registering a handler?
