Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Improve stack overflow handling #2757

Closed
Amanieu opened this issue Jan 19, 2022 · 0 comments · Fixed by #2807
Closed

Improve stack overflow handling #2757

Amanieu opened this issue Jan 19, 2022 · 0 comments · Fixed by #2807
Assignees
@Amanieu
Labels
bug Something isn't working priority-medium Medium priority issue
Milestone
v2.x

Comments

@Amanieu
Copy link
Contributor

Amanieu commented Jan 19, 2022

Wasmer's handling of stack overflows is rather poor: it assumes that any segfault that isn't tied to a Wasm memory access is a potential stack overflow and will longjmp back to the last host->wasm call. However this can potentially lead to deadlocks or memory corruption if the stack overflow happens in an unexpected place, such as the middle of malloc.

The solution is to not use the host stack when running Wasm code. If Wasm code executes on a separate stack then we can safely catch segfaults on the guard page of this stack and reset back to the last point where the secondary stack was entered. Any host code with non-trivial state or locking (e.g. malloc) must switch back to the host stack first for the duration of that call.
@Amanieu Amanieu self-assigned this Jan 19, 2022
@wchaudry wchaudry added this to the v2.x milestone Jan 25, 2022
@Amanieu Amanieu added priority-medium Medium priority issue bug Something isn't working labels Feb 9, 2022
Amanieu added a commit that referenced this issue Feb 25, 2022
@Amanieu
Run Wasm code on a separate stack
9e23d79 
This uses the [corosensei](https://crates.io/crates/corosensei) crate to
run Wasm code on a separate stack from the main thread stack.

In trap handlers for stack overflows and memory out of bounds accesses,
we can now check whether we are executing on the Wasm stack and reset
execution back to the main thread stack when returning from the trap
handler.

When Wasm code needs to perform an operation which may modify internal
data structures (e.g. growing a memory) then execution must switch back
to the main thread stack using on_host_stack. This is necessary to avoid
leaving internal data structure in an inconsistent state when a stack
overflow happens.

In the future, this can also be used to suspend execution of a Wasm
module (#1127) by modeling it as an async function call.

Fixes #2757
Fixes #2562
@Amanieu Amanieu mentioned this issue Feb 25, 2022
Merged
Amanieu added a commit that referenced this issue Feb 25, 2022
@Amanieu
Run Wasm code on a separate stack
f1262fb 
This uses the [corosensei](https://crates.io/crates/corosensei) crate to
run Wasm code on a separate stack from the main thread stack.

In trap handlers for stack overflows and memory out of bounds accesses,
we can now check whether we are executing on the Wasm stack and reset
execution back to the main thread stack when returning from the trap
handler.

When Wasm code needs to perform an operation which may modify internal
data structures (e.g. growing a memory) then execution must switch back
to the main thread stack using on_host_stack. This is necessary to avoid
leaving internal data structure in an inconsistent state when a stack
overflow happens.

In the future, this can also be used to suspend execution of a Wasm
module (#1127) by modeling it as an async function call.

Fixes #2757
Fixes #2562
Amanieu added a commit that referenced this issue Feb 25, 2022
@Amanieu
Run Wasm code on a separate stack
40302a8 
This uses the [corosensei](https://crates.io/crates/corosensei) crate to
run Wasm code on a separate stack from the main thread stack.

In trap handlers for stack overflows and memory out of bounds accesses,
we can now check whether we are executing on the Wasm stack and reset
execution back to the main thread stack when returning from the trap
handler.

When Wasm code needs to perform an operation which may modify internal
data structures (e.g. growing a memory) then execution must switch back
to the main thread stack using on_host_stack. This is necessary to avoid
leaving internal data structure in an inconsistent state when a stack
overflow happens.

In the future, this can also be used to suspend execution of a Wasm
module (#1127) by modeling it as an async function call.

Fixes #2757
Fixes #2562
bors bot added a commit that referenced this issue Mar 7, 2022
@bors @Amanieu
Merge #2807
cf6b96e 
2807: Run Wasm code on a separate stack r=syrusakbary a=Amanieu

This uses the [corosensei](https://crates.io/crates/corosensei) crate to
run Wasm code on a separate stack from the main thread stack.

In trap handlers for stack overflows and memory out of bounds accesses,
we can now check whether we are executing on the Wasm stack and reset
execution back to the main thread stack when returning from the trap
handler.

When Wasm code needs to perform an operation which may modify internal
data structures (e.g. growing a memory) then execution must switch back
to the main thread stack using on_host_stack. This is necessary to avoid
leaving internal data structure in an inconsistent state when a stack
overflow happens.

In the future, this can also be used to suspend execution of a Wasm
module (#1127) by modeling it as an async function call.

Fixes #2757
Fixes #2562


Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
bors bot added a commit that referenced this issue Mar 16, 2022
@bors @Amanieu
Merge #2807
fc794ab 
2807: Run Wasm code on a separate stack r=Amanieu a=Amanieu

This uses the [corosensei](https://crates.io/crates/corosensei) crate to
run Wasm code on a separate stack from the main thread stack.

In trap handlers for stack overflows and memory out of bounds accesses,
we can now check whether we are executing on the Wasm stack and reset
execution back to the main thread stack when returning from the trap
handler.

When Wasm code needs to perform an operation which may modify internal
data structures (e.g. growing a memory) then execution must switch back
to the main thread stack using on_host_stack. This is necessary to avoid
leaving internal data structure in an inconsistent state when a stack
overflow happens.

In the future, this can also be used to suspend execution of a Wasm
module (#1127) by modeling it as an async function call.

Fixes #2757
Fixes #2562


Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
@bors bors bot closed this as completed in ca6f83c Mar 16, 2022
ptitSeb pushed a commit that referenced this issue Oct 20, 2022
@Amanieu @ptitSeb
Run Wasm code on a separate stack
c50bed3 
This uses the [corosensei](https://crates.io/crates/corosensei) crate to
run Wasm code on a separate stack from the main thread stack.

In trap handlers for stack overflows and memory out of bounds accesses,
we can now check whether we are executing on the Wasm stack and reset
execution back to the main thread stack when returning from the trap
handler.

When Wasm code needs to perform an operation which may modify internal
data structures (e.g. growing a memory) then execution must switch back
to the main thread stack using on_host_stack. This is necessary to avoid
leaving internal data structure in an inconsistent state when a stack
overflow happens.

In the future, this can also be used to suspend execution of a Wasm
module (#1127) by modeling it as an async function call.

Fixes #2757
Fixes #2562
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Amanieu Amanieu

Labels
bug Something isn't working priority-medium Medium priority issue
Projects
None yet
Milestone
v2.x
Development

Successfully merging a pull request may close this issue.

Run Wasm code on a separate stack wasmerio/wasmer
2 participants
@Amanieu @wchaudry