[lld][WebAssembly] `--stack-first` should be the default for wasm-ld

[whitequark]

There are several arguments in favor of doing so:

• With stack protectors disabled by default, no dynamic stack overflow checks, a default stack size of 64K (the smallest of any non-bare-metal platform), and no memory protection, WebAssembly is uniquely vulnerable to stack smashing in a way that only the simplest microcontrollers that lack an MPU also are.
• Even ignoring the security aspect, the developer experience of encountering a stack overflow in the wild is confusing and difficult to recognize even for a professional systems developer, tools like Wasmtime's wmemcheck do not recognize it as a stack overflow specifically, and LLVM's suite of sanitizers isn't available to detect it when building for Wasm.
  • Emscripten provides stack overflow checks and ASan/MSan/UBSan, but ths isn't available on stock LLVM/Clang and wasi-sdk. (UBSan support could conceivably be polyfilled by an end user but the rest require compiler patches.)
• Using --stack-first has no code size overhead for the resulting artifact when otherwise default linker options are used.
  • Using --stack-first in conjunction with --compress-relocations has well below 1% size overhead.
• Other languages like Rust and Zig pass this option by default for the same reasons.

Although the memory control proposal will mitigate the need for this change, that proposal doesn't negate the need to make --stack-first the default now:

• Memory control is a Phase 1 proposal with uncertain design and adoption. We need to solve the problems listed above yesterday.
• Without inserting stack probes, using guard pages won't be enough to eliminate stack smashing for functions that use VLAs or alloca, so even if memory control was widely available, --stack-first has its merit until stack probes are implemented in LLVM for WebAssembly and enabled by default.

[llvmbot]

@llvm/issue-subscribers-lld-wasm

Author: Catherine (whitequark)

There are several arguments in favor of doing so: - Without stack protectors enabled by default, any dynamic stack overflow checks, a default stack size of 64K (the smallest of any platform), and no memory protection, WebAssembly is [uniquely vulnerable](https://arxiv.org/abs/2410.17925) to stack smashing in a way that only the simplest microcontrollers that lack an MPU also are. - Even ignoring the security aspect, the developer experience of encountering a stack overflow in the wild is [confusing and difficult to recognize even for a professional systems developer](https://github.com/WebAssembly/wasi-sdk/issues/551), tools like Wasmtime's `wmemcheck` do not recognize it as a stack overflow specifically, and LLVM's suite of sanitizers isn't available to detect it when building for Wasm. - Using `--stack-first` has [no code size overhead](https://github.com/WebAssembly/wasi-sdk/issues/551#issuecomment-3127799692) for the resulting artifact when otherwise default linker options are used. - Using `--stack-first` in conjunction with `--compress-relocations` has [well below 1% size overhead](https://github.com/WebAssembly/wasi-sdk/issues/551#issuecomment-3127841325). - Other languages like Rust and Zig pass this option by default for the same reasons.

Although the memory control proposal will mitigate the need for this change, that proposal doesn't negate the need to make --stack-first the default now:

• Memory control is a Phase 1 proposal with uncertain design and adoption. We need to solve the problems listed above yesterday.
• Without inserting __stkchk calls, using guard pages won't be enough to eliminate stack smashing for functions that use VLAs or alloca, so even if memory control was widely available, --stack-first has its merit.

[sbc100]

I don't have a strong aversion to changing the default, assuming we can be reasonably sure that existing users won't be broken by the change.

BTW, the tooling situation I believe is not quite has dire are you describe. Binaryen has a stack-check pass (https://github.com/WebAssembly/binaryen/blob/f8e164d9b85216f15eb2aa1494029b602bf0da53/src/passes/StackCheck.cpp#L17-L21) that emscripten users can activate using the -sSTACK_OVERFLOW_CHECK settings: https://emscripten.org/docs/tools_reference/settings_reference.html#stack-overflow-check. Also, llvm's sanitizers (with the exception of tsan) do work with wasm (at least in emscripten they do). I don't know off the top of my head if any of them specifically deal with stack OOB errors.

[whitequark]

Thanks, I wasn't aware of binaryen's pass. I think I tried sanitizers and they didn't work, but this might've been due to some other issue. I'll update the issue once I have a chance.

I mainly use wasi-sdk so it could be due to that.

[whitequark]

@sbc100 Looks like ASAN, MSAN, and UBSAN do not work on stock wasi-sdk:

$ /opt/wasi-sdk/bin/clang -fsanitize=memory test.c -o test.wasm
clang: error: unsupported option '-fsanitize=memory' for target 'wasm32-unknown-wasi'
$ /opt/wasi-sdk/bin/clang -fsanitize=address test.c -o test.wasm
clang: error: unsupported option '-fsanitize=address' for target 'wasm32-unknown-wasi'
$ /opt/wasi-sdk/bin/clang -fsanitize=undefined test.c -o test.wasm
wasm-ld: error: /tmp/test-106016.o: undefined symbol: __ubsan_handle_pointer_overflow
wasm-ld: error: /tmp/test-106016.o: undefined symbol: __ubsan_handle_type_mismatch_v1
clang: error: linker command failed with exit code 1 (use -v to see invocation)

It is good that we have that for Emscripten but it does mean that a significant chunk of the ecosystem is cut off from essential tooling at the moment.

[whitequark]

As an experiment I tried modifying wasi-sdk to get at least UBSan support and it looks like it requires at least one LLVM patch and also fairly extensive updates of the wasi-sdk build infrastructure, so I feel that the sanitizer situation is quite bad (unless you're relying on emscripten which you can't really do if you target WASI).

[sbc100]

Maybe file bugs against wasi-sdk for asan and ubsan support if such bugs don't exist already. One problem is that wasi-libc and wasi-sdk don't have lot of folks who can dedicate real time to supporting it. I'm sure any cycles you have there would be much appreciated. On the emscripten side there is likely some upstream work to do on the compiler-rt support for sanitizers too.

[whitequark]

Yeah. I'm sure you've noticed that I've tried to pick up some slack on wasi-sdk over the years. The sysroot build process is especially lengthy and somewhat byzantine or I'd already be submitting patches. I will almost certainly get around to it at some point, it's the exact kind of esoteric and high-impact compiler problem that I like. Still, it takes a lot of effort.

I'm a bit sad that the focus on emscripten means wasi-sdk doesn't get enough love but ultimately it's just life.

[whitequark]

@sbc100: Done WebAssembly/wasi-sdk#552 WebAssembly/wasi-sdk#553