GH-130397: remove special-casing of C stack depth for WASI

[brettcannon]

Along the way disable some tests which now fail (which were already disabled under Emscripten).

This doesn't pose any sercurity risk thanks to WebAssembly's stack protection.

• Issue: Implement stack overflow protection for webassembly #130397

[miss-islington-app]

Thanks @brettcannon for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

[bedevere-app]

GH-134547 is a backport of this pull request to the 3.14 branch.

[markshannon]

One of us is misunderstanding the way stacks work in C compiled to webassembly.

As I understand it, there are two stacks: the built in webassembly stack which does have built in protected and and additional stack for arrays and other objects that can have their address taken on the stack. This second stack has no built in protection.

Removing the protection we provide makes it possible to trash the heap and could perhaps introduce security vulnerabilities.

@hoodmane is this correct?

[markshannon]

What I think we should be doing is reducing the size of the webassembly stack and increasing the size of the in-heap stack, such that the majority of stack overflows are caught by our stack protection mechanism and reported as an exception.

[brettcannon]

One of us is misunderstanding the way stacks work in C compiled to webassembly.

Quite possibly (and it very well could be me).

As I understand it, there are two stacks: the built in webassembly stack which does have built in protected and and additional stack for arrays and other objects that can have their address taken on the stack. This second stack has no built in protection.

Removing the protection we provide makes it possible to trash the heap and could perhaps introduce security vulnerabilities.

Maybe, but I also need to be able to parse Python code in WASI in a debug build and this was the only way I could find how without sinking days into trying to make this all work (assuming it would as I already spent days up to this point).

What I think we should be doing is reducing the size of the webassembly stack and increasing the size of the in-heap stack, such that the majority of stack overflows are caught by our stack protection mechanism and reported as an exception.

If you can explain how to make that happen or make a PR for that then that would be great. But I tried tweaking all of the numbers I had available to me and it never seemed to turn out to a result that didn't cause some critical test failure because the stack got too small.

[markshannon]

If you can explain how to make that happen or make a PR for that then that would be great. But I tried tweaking all of the numbers I had available to me and it never seemed to turn out to a result that didn't cause some critical test failure because the stack got too small.

Um, you're the WASI expert. This is a WASI build thing, probably Clang or linker flags.
Once that's done, the C stack limit in Python should reflect that actual stack size that llvm/the linker allocates.

[hoodmane]

Stack size is set here:

cpython/configure.ac

Line 2388 in b706ff0

AS_VAR_APPEND([LDFLAGS_NODIST], [" -z stack-size=16777216 -Wl,--stack-first -Wl,--initial-memory=41943040"])

[brettcannon]

Um, you're the WASI expert.

I'm aware of that, hence me saying as the WASI expert -- along with Hood being a WASM expert and very knowledgeable about WASI -- it isn't working for WASI unless there's something we're missing (but I believe you sent this before the discussion on Discord).