Stream: git-wasmtime

Topic: wasmtime / issue #10408 x64: Misaligned load fault with s...

Wasmtime GitHub notifications bot (Mar 17 2025 at 14:58):

alexcrichton added the cranelift:area:x64 label to Issue #10408.

Wasmtime GitHub notifications bot (Mar 17 2025 at 14:58):

alexcrichton added the fuzz-bug label to Issue #10408.

Wasmtime GitHub notifications bot (Mar 17 2025 at 14:58):

alexcrichton opened issue #10408:

Currently on the main branch this fails:

$ cargo run -q wast --target x86_64-unknown-linux-gnu -Oopt-level=0 ./tests/misc_testsuite/issue4890.wast
Error: failed to run script file './tests/misc_testsuite/issue4890.wast'

Caused by:
    0: failed directive on ./tests/misc_testsuite/issue4890.wast:12:1
    1: error while executing at wasm backtrace:
           0:   0x2f - <unknown>!<wasm function 0>
    2: wasm trap: out of bounds memory access

This test shouldn't fail, however, and it should pass. Bisection points to #10316 (ddaaed60aea235b7047de25db050224d26a28060).

Using https://github.com/bytecodealliance/wasmtime/pull/10405 I get

$ cargo run -q objdump foo.cwasm --traps --addresses
00000000 wasm[0]::function[0]:
         0: pushq   %rbp
         1: movq    %rsp, %rbp
         4: movl    %edx, %r11d
         7: addq    0x50(%rdi), %r11
         b: movl    $0x80000000, %r8d
        11: movd    %r8d, %xmm1
        16: movdqa  %xmm1, %xmm0
        1a: andnps  0xf(%rip), %xmm0
        21: andps   1(%r11), %xmm1
            ╰─╼ trap: MemoryOutOfBounds
        26: orps    %xmm1, %xmm0
        29: movq    %rbp, %rsp
        2c: popq    %rbp
        2d: retq
        2e: addb    %al, (%rax)
        30: addb    %al, (%rax)
        32: addb    %al, (%rax)
        34: addb    %al, (%rax)
        36: addb    %al, (%rax)
        38: addb    %al, (%rax)
        3a: addb    %al, (%rax)
        3c: addb    %al, (%rax)
        3e: addb    %al, (%rax)

and the bug here is indeed that MemoryOutOfBounds trap happening. That's due to misalignment though instead of something being out-of-bounds so we're erroneously catching the segfault.

cc @abrown @rahulchaphalkar

Wasmtime GitHub notifications bot (Mar 17 2025 at 14:59):

alexcrichton commented on issue #10408:

I'll note that this is NOT on the release-31.0.0 branch, so this does not affect the pending release in a few days, so we have ~6 weeks to fix this.

Wasmtime GitHub notifications bot (Mar 17 2025 at 15:16):

alexcrichton commented on issue #10408:

I tried double-checking just now, but ideally we wouldn't catch segfaults related to misalignment at all. I'm not sure if misalignment faults look different from normal segfaults though at the hardware level, but at the libc level they seem to look the same. Debugging some fields in siginfo_t I get:

si_code=128
si_errno=0
si_signo=11
si_trapno=0

where it looks like nothing is alignment-vs-unmapped here. The si_code means "is from the kernel" and si_signo is SIGSEGV.

Wasmtime GitHub notifications bot (Mar 17 2025 at 20:46):

alexcrichton commented on issue #10408:

Hm ok correction: the release-31.0.0 branch does contain https://github.com/bytecodealliance/wasmtime/pull/10273 (e33c4269589a4f97c572d579240b3349534872fa) which may be affected by this. This test itself does not literally fail on the release branch. Manually auditing rules I don't think that load-sinking behavior is reachable from x64_orpd, all arguments are always Xmm except for the bor instruction in Cranelift which isn't supported on floats in wasm anyway.

Wasmtime GitHub notifications bot (Mar 18 2025 at 14:44):

alexcrichton closed issue #10408:

Currently on the main branch this fails:

$ cargo run -q wast --target x86_64-unknown-linux-gnu -Oopt-level=0 ./tests/misc_testsuite/issue4890.wast
Error: failed to run script file './tests/misc_testsuite/issue4890.wast'

Caused by:
    0: failed directive on ./tests/misc_testsuite/issue4890.wast:12:1
    1: error while executing at wasm backtrace:
           0:   0x2f - <unknown>!<wasm function 0>
    2: wasm trap: out of bounds memory access

This test shouldn't fail, however, and it should pass. Bisection points to #10316 (ddaaed60aea235b7047de25db050224d26a28060).

Using https://github.com/bytecodealliance/wasmtime/pull/10405 I get

$ cargo run -q objdump foo.cwasm --traps --addresses
00000000 wasm[0]::function[0]:
         0: pushq   %rbp
         1: movq    %rsp, %rbp
         4: movl    %edx, %r11d
         7: addq    0x50(%rdi), %r11
         b: movl    $0x80000000, %r8d
        11: movd    %r8d, %xmm1
        16: movdqa  %xmm1, %xmm0
        1a: andnps  0xf(%rip), %xmm0
        21: andps   1(%r11), %xmm1
            ╰─╼ trap: MemoryOutOfBounds
        26: orps    %xmm1, %xmm0
        29: movq    %rbp, %rsp
        2c: popq    %rbp
        2d: retq
        2e: addb    %al, (%rax)
        30: addb    %al, (%rax)
        32: addb    %al, (%rax)
        34: addb    %al, (%rax)
        36: addb    %al, (%rax)
        38: addb    %al, (%rax)
        3a: addb    %al, (%rax)
        3c: addb    %al, (%rax)
        3e: addb    %al, (%rax)

and the bug here is indeed that MemoryOutOfBounds trap happening. That's due to misalignment though instead of something being out-of-bounds so we're erroneously catching the segfault.

cc @abrown @rahulchaphalkar

Last updated: Apr 18 2025 at 15:03 UTC