Implement interrupting wasm code, reimplement stack overflow

[alexcrichton]

This commit is a relatively large change for wasmtime with two main
goals:

• Primarily this enables interrupting executing wasm code with a trap,
  preventing infinite loops in wasm code. Note that resumption of the
  wasm code is not a goal of this commit.

• Additionally this commit reimplements how we handle stack overflow to
  ensure that host functions always have a reasonable amount of stack to
  run on. This fixes an issue where we might longjmp out of a host
  function, skipping destructors.

Lots of various odds and ends end up falling out in this commit once the
two goals above were implemented. The strategy for implementing this was
also lifted from Spidermonkey and existing functionality inside of
Cranelift. I've tried to write up thorough documentation of how this all
works in crates/environ/src/cranelift.rs where gnarly-ish bits are.

A brief summary of how this works is that each function and each loop
header now checks to see if they're interrupted. Interrupts and the
stack overflow check are actually folded into one now, where function
headers check to see if they've run out of stack and the sentinel value
used to indicate an interrupt, checked in loop headers, tricks functions
into thinking they're out of stack. An interrupt is basically just
writing a value to a location which is read by JIT code.

When interrupts are delivered and what triggers them has been left up to
embedders of the wasmtime crate. The wasmtime::Store type has a
method to acquire an InterruptHandle, where InterruptHandle is a
Send and Sync type which can travel to other threads (or perhaps
even a signal handler) to get notified from. It's intended that this
provides a good degree of flexibility when interrupting wasm code. Note
though that this does have a large caveat where interrupts don't work
when you're interrupting host code, so if you've got a host import
blocking for a long time an interrupt won't actually be received until
the wasm starts running again.

Some fallout included from this change is:

• Unix signal handlers are no longer registered with SA_ONSTACK.
  Instead they run on the native stack the thread was already using.
  This is possible since stack overflow isn't handled by hitting the
  guard page, but rather it's explicitly checked for in wasm now. Native
  stack overflow will continue to abort the process as usual.

• Unix sigaltstack management is now no longer necessary since we don't
  use it any more.

• Windows no longer has any need to reset guard pages since we no longer
  try to recover from faults on guard pages.

• On all targets probestack intrinsics are disabled since we use a
  different mechanism for catching stack overflow.

• The C API has been updated with interrupts handles. An example has
  also been added which shows off how to interrupt a module.

Closes #139
Closes #860
Closes #900

[github-actions]

Subscribe to Label Action

This issue or pull request has been labeled: "cranelift", "fuzzing", "wasmtime:api", "wasmtime:c-api"

Users Subscribed to "cranelift"

• @bnjbvr

Users Subscribed to "fuzzing"

• @fitzgen

Users Subscribed to "wasmtime:api"

• @peterhuene

Users Subscribed to "wasmtime:c-api"

• @peterhuene

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[fitzgen]

Haven't looked at the code yet, but I have a question:

The wasmtime::Store type has a
method to acquire an InterruptHandle,

Does this mean that the finest granularity of interrupt is a store?

That seems fine for now, in the single-threaded wasm world, but will likely need reworking to be finer grained when we support threads. Do you have an idea how much more work it would be to make this per-instance?

[alexcrichton]

@fitzgen yeah adapting this shouldn't be too hard at all, it's just a shared Arc data structure and it would be easy to arrange all instances linked together to have access to that Arc

[github-actions]

Subscribe to Label Action

This issue or pull request has been labeled: "wasi"

Users Subscribed to "wasi"

• @kubkon

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[fitzgen]

assert that the size is greater than zero? (or some reasonable min)

[alexcrichton]

I don't think it'd help much to single-out zero here, 1 byte of stack allocation is just as nonsensical in a sense. I personally think it's ok to take everything here, and if someone is toying around with 0-byte wasm stacks for testing that seems like it's fine to allow.

[fitzgen]

Also add a test for this file over here: https://github.com/bytecodealliance/wasmtime/blob/master/crates/c-api/tests/wasm-c-examples.rs

[alexcrichton]

Hm I don't think this is actually that necessary, we already run all the examples on CI with cargo run -p run-examples?

[fitzgen]

Ah ok, I guess #1463 was unnecessary

[pepyakin]

Looks just great! A couple of nits

[alexcrichton]

Ok I've pushed up a commit which uses a GlobalValue for the stack limit instead of a closure, and there's a "mini interpreter" of this GlobalValue since ins().global_value(...) can't be used this late after legalization. It's hopefully sufficient enough for now but also with better future-compatibility.

I'm not really sure how to serialize this out or parse it in the text format. If that's required can folks point me in the right direction of how to do that?

[bjorn3]

You should serialize it in write_function and then parse it in cranelift-reader.

[alexcrichton]

Ok @sunfishcode, should be updated!

[alexcrichton]

Ok after some discussion with @sunfishcode I brought back the SA_ONSTACK flag so we can be sure to still execute the fallback to libstd's segfault handler on the sigaltstack. We already have the code to make the sigaltstack bigger, so that should cover our own purposes for now as well. This means that all signals still go through the sigaltstack.

[sunfishcode]

This looks good; the one thing left to do is serialize/deserialize the stack_limit field in ir::Function. This probably should be a new declaration in the preamble (see parse_preamble in cranelift/reader/src/parser.rs and write_preamble in cranelift/codegen/src/write.rs, with a syntax like "stack_limit = gv0" or so. I can answer any questions about this code, or if you want, we could probably defer this part to a separate PR, as the PR here is already pretty big.

[alexcrichton]

Ok the last commit should be the stack limit parsing via the syntax you suggested

[sunfishcode]

Looks good! There's now just the two CI failures. One is an easy fix I just commented on above.

There other is a failure in host_segfault.rs on macos-latest CI:

     Running target/release/deps/host_segfault-de61d05b549d9afb

thread 'main' panicked at 'assertion failed: stderr.contains("thread 'main' has overflowed its stack")', tests/host_segfault.rs:95:9
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::begin_panic
   7: host_segfault::main
   8: std::rt::lang_start::{{closure}}
   9: std::panicking::try::do_call
  10: __rust_maybe_catch_panic
  11: std::rt::lang_start_internal
  12: main

[alexcrichton]

Ok all green now!

[sunfishcode]

Great!