[llvm-bugs] [Bug 51173] New: wasm-ld: stack corruption due to limited unsafe stack size

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51173

            Bug ID: 51173
           Summary: wasm-ld: stack corruption due to limited unsafe stack
                    size
           Product: lld
           Version: 12.0
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: wasm
          Assignee: unassignedbugs at nondot.org
          Reporter: shravanrn at gmail.com
                CC: llvm-bugs at lists.llvm.org, sbc at chromium.org

Hi, 
We are using Wasm to sandbox libraries in the Mozilla Firefox browser and ran
into an issue when running one of our compiled libraries to Wasm.

It looks like wasm-ld allocates a 64K unsafe wasm stack (the portion of the C
stack that is moved in to wasm linear memory due to use of pointer arithmetic).
While this works well in most of the cases, we recently ran into a library that
uses more space than this, when compiled at O0 (it uses less space on the
unsafe stack when the C code is optimized)

At this time, it looks like there is no way to change the threshold in wasm-ld.
it would be nice to add a flag to allow for a larger stack size (I also tried
using --stack-first and --global-base together as an indirect way to get the
desired behavior) but this doesn't work

Beyond the basic stack size issue, I do want to point out there is potentially
a more pressing issue here --- compiling code to wasm that needs more unsafe
stack space than available does not immediately crash. Instead, it starts
silently overwriting other portions of linear memory, and this eventually leads
to a crash. This is problematic as this behavior tends to look like a very
random crash and is hard to diagnose especially for novel users.  

I believe beyond the flag to specify the custom size of the stack, one of three
things may need to be done

1) Implement the --stack-first behavior by default: Right now C globals are
placed in linear memory prior to the unsafe stack which means underflow of the
unsafe stack will clobber the C globals silently. --stack-first will mean that
an underflow of the stack will wrap around and likely cause bounds check
failures (assuming the wasm module isn't using all 4GB of linear memory)

2) Implement bounds checks on unsafe stack expansion: Although this is perhaps
something that needs to be done at the codegen level? Additionally, I am not
sure what the performance impact of this approach would be.

For the moment I am manually expanding the unsafe stack to a larger allocation,
but it would be nice to have a better fix.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210723/ae377ade/attachment.html>