wasm4: [BUG] Stack overflow silently corrupts data and vice versa

WARNING: this bug is relevant for every language!

To detect stack overflow rustc places stack before anything else (see explanation). As you may know, stack grows backwards. Therefore to detect stack overflow it is basically placed at the top of the module’s memory, and if stack pointer underflows and then is dereferenced, it throws an exception. Because of the memory map being at the top, it is not possible to detect stack overflow and it allows for stack overflow to silently corrupt some data on its way or vice versa.

See solutions: https://github.com/aduros/wasm4/issues/255#issuecomment-1002187910

I want to fix this bug, but we all need to agree on a solution.

About this issue

Original URL
State: open
Created 3 years ago
Comments: 22 (22 by maintainers)

Most upvoted comments

I’m not too crazy about any of the proposed solutions. I think having WASM-4’s system memory at a variable address would introduce too much complexity. The proposal about moving the WASM-4 system memory after the stack but before the global base is interesting but not really feasible at least for LLVM-based languages (the --global-base option is ignored if --stack-first is used).

At the moment this is affecting primarily Rust because the linker there uses --stack-first. I think we should:

Use --stack-first on all other languages too. It’s probably better that a stack overflow corrupts the framebuffer rather than static program memory.
Increase the stack-size to 8 KB + the 6560 bytes of WASM-4 system memory (since the stack envelopes WASM-4 memory when using --stack-first)
Sentinel: Have an option to make the devtools watch around byte 6560 and if non-zero, raise an error. This isn’t perfect for the reasons you mentioned but it would at least tell the user that an error has occured and they should either increase the stack size or change their program.

aduros on Jan 9, 2022

@joshgoebel let’s not focus on it. It’s not relevant. The bug is pretty bad anyway as it triggers UB.

zetanumbers on Dec 28, 2021

IMHO: This is simply something our “hardware” doesn’t allow because of our hard-wired RAM layout. I personally don’t think we should change WASM-4 overall (or add complexity) to accommodate a single compiler option from a single language. (even IF it is an agreeably useful feature)

If it was to be considered at all it should be only after having exhausted all simpler options (that are already possible, and do not requires any changes to WASM-4).

As I pointed out there are already simple ways to do this easily enough (just like you’d do it in any of the other languages we support)… just nothing you get “for free”… of course it’s not truly “for free” at all if it requires a lot of changes to the WASM-4 “hardware” just to support it…

joshgoebel on Dec 28, 2021

Please explain exactly what you are moving when you say “memory map”… do you mean the entire documented registers and VRAM, etc?

The whole thing: https://wasm4.org/docs/reference/memory

zetanumbers on Dec 28, 2021