You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AOT compiler shows inconsistent memory side-effects when trap occurs. The PoC code is the following:
(module
(type(;0;) (func))
(func(;0;) (type0)
i32.const0i32.const0v128.consti32x40xffffffff0xffffffff0xffffffff0xffffffffv128.storeoffset=4align=2;; offset larger than 4 (offset 4 is tainted)i32.const4i32.const-1i32.loadalign=1;; this load fails (traps here)i32.eqv128.load8_splatalign=1v128.storeoffset=4align=2) ;; same offset
(memory(;0;)1)
(export"mem" (memory0))
(export"main" (func0)))
There are three noticable points: two v128.store and one i32.load. First, the first v128.store writes value to the memory at offset 4. Then, 16 bytes from offset 4 should be filled with 0xff. Second, the program traps at i32.load due to invalid offset -1. Then, the program should terminate while having memory side-effect at offset 4.
However, due to optimizations, at O2 and higher, memory is left as unwritten at the time the program traps. My guess here is that due to instruction scheduling, the order of two v128.stores are switched so that the memory side-effect did not occur. To explain more, the trap occurs first before the memory is written at 0x4.
Current State
Using AOT compiler and executing the above wasm program gives the memory side-effect inconsistently. For O1 and non-AOT, the memory at offset 4 is properly written with 0xff. (total 16 bytes, offset 4~19) For O2 to Oz, the memory is unchanged.
That is, the expected memory state at the end is the following:
Summary
AOT compiler shows inconsistent memory side-effects when trap occurs. The PoC code is the following:
There are three noticable points: two v128.store and one i32.load. First, the first v128.store writes value to the memory at offset 4. Then, 16 bytes from offset 4 should be filled with 0xff. Second, the program traps at i32.load due to invalid offset -1. Then, the program should terminate while having memory side-effect at offset 4.
However, due to optimizations, at O2 and higher, memory is left as unwritten at the time the program traps. My guess here is that due to instruction scheduling, the order of two v128.stores are switched so that the memory side-effect did not occur. To explain more, the trap occurs first before the memory is written at 0x4.
Current State
Using AOT compiler and executing the above wasm program gives the memory side-effect inconsistently. For O1 and non-AOT, the memory at offset 4 is properly written with 0xff. (total 16 bytes, offset 4~19) For O2 to Oz, the memory is unchanged.
That is, the expected memory state at the end is the following:
However, the memory becomes like:
Expected State
The value 0xff should be written at offset 4~19 at the time when the program terminates. This should be done regardless of optimizations.
Reproduction steps
Run with:
(I did not check this code - but it will work..)
Screenshots
Any logs you want to share for showing the specific issue
No response
Components
Rust SDK
WasmEdge Version or Commit you used
0.13.5
Operating system information
Ubuntu 22.04
Hardware Architecture
x86_64
Compiler flags and options
Cmake version: 3.22.1
Command:
cmake -DCMAKE_BUILD_TYPE=Release -DWASMEDGE_BUILD_TESTS=ON -DCMAKE_C_COMPILER=clang-19 -DCMAKE_CXX_COMPILER=clang++-19 -DCMAKE_CXX_FLAGS="-Wno-deprecated-declarations" .. && make -j
Cargo, rustc: 1.79.0-nightly
The text was updated successfully, but these errors were encountered: