SDK should support Address Sanitizer

[whitequark]

Per llvm/llvm-project#151015 (comment).

Right now, it is just disabled:

$ /opt/wasi-sdk/bin/clang -fsanitize=address test.c
clang: error: unsupported option '-fsanitize=address' for target 'wasm32-unknown-wasi'

Personally, I don't really know how ASan would work, since I believe it relies on a block of shadow memory somewhere high in address space normally. Would that be just a new linear memory just for that purpose? I'm not familiar with ASan implementation, I assume @sbc100 knows how it is supposed to work.

[SingleAccretion]

Would that be just a new linear memory just for that purpose?

I believe the way it works in Emscripten is by reserving the first ~1/8 of the linear memory (as if there was a very large static data block): https://github.com/emscripten-core/emscripten/blob/be3fe6b97b358a389bfa8a9745c5c7f94a4eb293/tools/link.py#L1626-L1653.

[whitequark]

It sounds like my idea would be both a lot more efficient (since you could grow the second region alongside the first instead of reserving 512 MB if you want to be able to grow to 4 GB) and impossible to overwrite if you have a write-what-where primitive.

[kateinoigakukun]

I have been working on porting ASan for WASI as a part of Swift project. I've already upstreamed some of the changes. You can find more details here:
swiftwasm/swift#5609

[whitequark]

Oh, brilliant! I'll leave it to you then.

[whitequark]

@kateinoigakukun Have you solved a problem where sanitizer_redefine_builtins.h crashes Clang in WasmObjectWriter::writeOneObject?

[kateinoigakukun]

@whitequark Yeap, I just excluded the inline asm block, and it was enough to make it work. I haven't took a closer look at the reason for the inline asm though.

kateinoigakukun/llvm-project@81a04b4

[whitequark]

@kateinoigakukun This will cause problems: the compiler will generate calls to memcpy within the sanitizer itself, which may be intercepted and incorrectly treated as application code. You'd have to teach it to pass -fno-builtins or -mllvm -disable-simpilfy-libcalls to the compiler when building for Wasm.

How did you redefine GET_CALLER_PC()?

[kateinoigakukun]

Yeah, that's definitely not a proper solution; we need to find a way to work around it.

For GET_CALLER_PC(), I just redefined it to return 0 kateinoigakukun/llvm-project@1fa0b8d

[whitequark]

Redefining it to return 0 hides all of the reports.