Stream: git-wasmtime

Topic: wasmtime / issue #6028 Validate faulting addresses are va...

Wasmtime GitHub notifications bot (Mar 15 2023 at 21:45):

github-actions[bot] commented on issue #6028:

Subscribe to Label Action

cc @peterhuene

<details>
This issue or pull request has been labeled: "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:api

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

Learn more.
</details>

Wasmtime GitHub notifications bot (Mar 15 2023 at 23:44):

github-actions[bot] commented on issue #6028:

Subscribe to Label Action

cc @fitzgen

<details>
This issue or pull request has been labeled: "fuzzing"

Thus the following users have been cc'd because of the following labels:

• fitzgen: fuzzing

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

Learn more.
</details>

Wasmtime GitHub notifications bot (Mar 16 2023 at 14:42):

alexcrichton commented on issue #6028:

A high-level question as well: a pagefault from within a hostcall won't trigger the warning, right? Or do we enter the handler if an instance in the store is on the stack at all?

Correct, yeah. We've actually got tests which ensure that a host-triggered segfault isn't caught by Wasmtime and aborts the process (as you'd expect a segfault in a language like Rust to do so). The first thing the signal handlers do is test whether the faulting pc is a wasm pc, and it defers to the default behavior of each signal if it's not a wasm pc. If it's a wasm pc though we fully catch the trap assuming it's expected that the wasm instruction had the kind of fault.

Wasmtime GitHub notifications bot (Mar 16 2023 at 21:44):

alexcrichton commented on issue #6028:

@uweigand I was wondering if I could enlist your help to debug a failure here. This has failed in CI with this error:

---- traps::wasm_fault_address_reported_by_default stdout ----
thread 'traps::wasm_fault_address_reported_by_default' panicked at 'bad error: error while executing at wasm backtrace:
    0:   0x25 - <unknown>!start

Caused by:
    0: memory fault at wasm address 0xdeadb000 in linear memory of size 0x10000
    1: wasm trap: out of bounds memory access', tests/all/traps.rs:1308:5

where this is the module being executed:

            (module
                (memory 1)
                (func $start
                    i32.const 0xdeadbeef
                    i32.load
                    drop)
                (start $start)
            )

and the test is asserting:

    let err = format!("{err:?}");
    assert!(
        err.contains("memory fault at wasm address 0xdeadbeef in linear memory of size 0x10000"),
        "bad error: {err}"
    );

so it seems like s390x is reporting the faulting address of the load instruction is something page-rounded (or something like that?). I don't know how to hook up gdb to qemu but in theory this means that the address coming out of siginfo_t's si_addr field in the signal handler doesn't have the 0xeef at the end and instead ends in 0x000 (I think).

Do you know if this is an s390x-specific behavior? Are faulting addresses reported at their page aligned boundary instead of the address itself?

Wasmtime GitHub notifications bot (Mar 17 2023 at 13:27):

uweigand commented on issue #6028:

Do you know if this is an s390x-specific behavior? Are faulting addresses reported at their page aligned boundary instead of the address itself?

Yes, this is correct. Faulting addresses are rounded to their 4k page boundary on s390x.

Wasmtime GitHub notifications bot (Mar 17 2023 at 14:28):

alexcrichton commented on issue #6028:

Ok good to know it's expected! I'll disable this particular test for s390x in that case.

Last updated: Oct 23 2024 at 20:03 UTC