Consider setting a dedicated signal handler stack to make sandbox stack overflows recoverable

[bushidocodes]

runtime/include/wasm_stack.h
	int rc        = munmap(stack->buffer, stack->capacity + PAGE_SIZE);
	stack->buffer = NULL;
	if (unlikely(rc == -1)) perror("munmap");
}

Member
@gparmer gparmer yesterday
You have any idea what happens if we set up a signal for SIG_TRAP, then trap out by hitting the guard page here? Normally the signal would execute on the stack....but....

Member
Author
@bushidocodes bushidocodes 21 hours ago
@gparmer - I would assume the signal handler would panic the process or something. I seem to recall that you can consider signal handlers to use a dedicated stack. Perhaps we should be doing that so a module stack overflow is recoverable?

[bushidocodes]

I thought through this a bit more. Currently, large objects on the stack are most likely going to end up on the stack placed by WASI-SDK within a sandbox's linear memory. If a stack overflow occurs there, the stack corrupts the data segment unless wasm-ld was configured to place the stack at the front of linear memory, in which case, the stack pointer would be decremented below 0 and overflow to some high address that would likely be beyond what the size of the linear memory, triggering a WebAssembly trap.

In contrast, the values on this stack are the WebAssembly locals, parameters, and operand stack generated by WASI-SDK or whatever other compiler generated the module. Given that this code is highly optimized, I assume that this pressure is less critical. sledgert has some parameters to customize this stack size, but we hardcode this to 512KB, which I consider a substantial overallocation that ameliorates the risk of the stack overflow situation discussed above.

If WebAssembly ends up adopting an object model that ends up shifting state from the in-memory stack to WebAssembly locals, this might change this dynamic. Otherwise, I don't think overflows are that big of a concern compared to the stack inside linear memory.

If we do want to deal with this, signaltstack(2) essentially has the complete sample code for setting up an alternate signal stack to deal with SIGSEGV.