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.

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

Add more address overflow tests #1188

Merged
merged 1 commit into from
Apr 29, 2020
Merged

Add more address overflow tests #1188

merged 1 commit into from
Apr 29, 2020

Conversation

binji
Copy link
Member

@binji binji commented Apr 28, 2020

There are already tests for effective address overflow, but those have a
large value baked into the offset. These tests all use 1 as the
immediate offset, and use -1 for the address on the stack, which may
be compiled differently.

There are already tests for effective address overflow, but those have a
large value baked into the offset. These tests all use `1` as the
immediate offset, and use `-1` for the address on the stack, which may
be compiled differently.
binji added a commit to WebAssembly/wabt that referenced this pull request Apr 29, 2020
This only occurs when the immediate offset is small (`int` sized). The
stack offset is `u32` and the immediate is an `int`, so the usual
arithmetic conversions converts the result to a `u32`, which wraps the
address before checking for overflow.

There are already spec tests for overflow, but these use an offset of
`4294967295`, which is `long` (at least on LP64 systems). This means
that the sum's type is `u32 + long` which is `long`. This is why the
tests pass. I've added additional tests for these cases here:
WebAssembly/spec#1188

This fixes issue #1400.
binji added a commit to WebAssembly/wabt that referenced this pull request Apr 29, 2020
This only occurs when the immediate offset is small (`int` sized). The
stack offset is `u32` and the immediate is an `int`, so the usual
arithmetic conversions converts the result to a `u32`, which wraps the
address before checking for overflow.

There are already spec tests for overflow, but these use an offset of
`4294967295`, which is `long` (at least on LP64 systems). This means
that the sum's type is `u32 + long` which is `long`. This is why the
tests pass. I've added additional tests for these cases here:
WebAssembly/spec#1188

This fixes issue #1400.
@binji binji merged commit d45188d into master Apr 29, 2020
@binji binji deleted the more-address-overflow-tests branch April 29, 2020 16:02
Honry added a commit to Honry/WAVM that referenced this pull request May 13, 2020
Echo to github.com/WebAssembly/spec/pull/1188,
add more address overflow tests with offset set
to `1` and address set to `-1`, which may be complied
differently.
AndrewScheidecker pushed a commit to WAVM/WAVM that referenced this pull request May 13, 2020
Echo to github.com/WebAssembly/spec/pull/1188,
add more address overflow tests with offset set
to `1` and address set to `-1`, which may be complied
differently.
Honry added a commit to Honry/simd that referenced this pull request May 14, 2020
Echo to github.com/WebAssembly/spec/pull/1188,
add more address overflow tests with offset set
to `1` and address set to `-1`, which may be complied
differently.
tlively pushed a commit to WebAssembly/simd that referenced this pull request May 14, 2020
Echo to github.com/WebAssembly/spec/pull/1188,
add more address overflow tests with offset set
to `1` and address set to `-1`, which may be complied
differently.
gumb0 pushed a commit to wasmx/wasm-spec that referenced this pull request Sep 18, 2020
There are already tests for effective address overflow, but those have a
large value baked into the offset. These tests all use `1` as the
immediate offset, and use `-1` for the address on the stack, which may
be compiled differently.
gumb0 pushed a commit to wasmx/wasm-spec that referenced this pull request Sep 21, 2020
There are already tests for effective address overflow, but those have a
large value baked into the offset. These tests all use `1` as the
immediate offset, and use `-1` for the address on the stack, which may
be compiled differently.
rossberg added a commit that referenced this pull request Feb 11, 2021
* Upgrade to latest Sphinx release (2.4.4) (#1171)

Fixes #1157

* Support 4GB of memory both in initial and max.

* [interpreter] Strictify and specify .bin.wast format (#1173)

* Merge nontrapping-float-to-int proposal into spec (#1143)

See the non-trapping-float-to-int-conversions proposal here:

https://github.com/WebAssembly/nontrapping-float-to-int-conversions

* Merge sign-extension-ops proposal into spec (#1144)

See the sign-extension-ops proposal here:

https://github.com/WebAssembly/sign-extension-ops

This PR is built on top of #1143 (merge nontrapping-float-to-int).

* Merge multi-value proposal into spec (#1145)

See the multi-value proposal here:

https://github.com/WebAssembly/multi-value

This PR is built on top of the following PRs:

* #1143 (merge nontrapping-float-to-int)
* #1144 (merge sign-extension-ops)

* [interpreter] Remove junk in README

* [interpreter] Remove junk in README

* [spec] Fix grammar for fractions (#1178)

* [spec] Add missing i64.extend32_s syntax (#1179)

* [js-api][web-api] Fix some markup errors.

* Add a README to the proposals directory.

* Add more address overflow tests (#1188)

There are already tests for effective address overflow, but those have a
large value baked into the offset. These tests all use `1` as the
immediate offset, and use `-1` for the address on the stack, which may
be compiled differently.

* Add a test for non-treelike behavior of stack (#961)

We've recently found a bug in a WebAssembly library we've been working
with where we're mapping WebAssembly to a tree-like IR internally. The
way we parse into this representation, however, has a bug when the
function isn't itself tree-like but rather exibits properties that
exploit a stack machine. For example this isn't so straightforward to
represent in a tree-like fashion:

    (import "" "a" (func $foo))
    (import "" "b" (func $foo (result i32)))
    (func (result i32)
      call $b
      call $b
      call $a
      i32.xor)

The extra `call $a` in the middle is valid `WebAssembly` but needs
special treatment when converting to a more tree-like IR format. I
figured it'd be good to ensure there's a spec test covering this case as
we currently pass the suite of spec tests but still contain this bug!

* [js-api] Various editorial improvements.

* [js-api] Replace pseudo-ASCII characters by normal ones.

This also required disambiguating the references to "module", as there are now
two definitions by that name.

* [js-api] Improve prose in 'run a host function'.

* [js-api] Improve some of the multi-value prose.

* Synchronize js-api tests.

* Add script to synchronize js-api tests.

Co-authored-by: Ng Zhi An <[email protected]>
Co-authored-by: Alon Zakai <[email protected]>
Co-authored-by: Ben Smith <[email protected]>
Co-authored-by: Ms2ger <[email protected]>
Co-authored-by: Alex Crichton <[email protected]>
kenohassler pushed a commit to fgsect/WAFL that referenced this pull request Oct 18, 2021
Echo to github.com/WebAssembly/spec/pull/1188,
add more address overflow tests with offset set
to `1` and address set to `-1`, which may be complied
differently.
kateinoigakukun added a commit to kateinoigakukun/wasminspect that referenced this pull request Nov 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants