[llvm-dev] Using MSan as dso

[Marko Stanojlovic via llvm-dev]

Hello llvm developers,

Is there a way to use Memory Sanitizer when there is a third-party executable which cannot be recompiled,
but it loads shared libraries that can be recompiled and we want to test them with MSan? In other words could be MSan used as dso?

Similar to ASan usage described on its wiki page - https://github.com/google/sanitizers/wiki/AddressSanitizerAsDso. 

Kind regards and thanks in advance for response,

Marko Stanojlović

SYRMIA LLC @ Belgrade Office Park
Djordja Stanojevica 12,
Beograd 11070

[Mitch Phillips via llvm-dev]

Hi Marko,

Uninstrumented code under ASan leads to false negatives. Under MSan, uninstrumented code leads to false positives. MSan is thus not suitable to be used as a preloaded DSO.

If you're really, really, extremely dedicated and willing to annotate every instance where memory that's initialized in uninstrumented code flows to instrumented code, then you might be able to find some bugs. But it's worth bearing in mind that usage of MSan in this way is warranty-voiding.

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Marko Stanojlovic via llvm-dev]

Hi Mitch,

Thank you for quick response.

Since MSan is usable as dso it would be very nice if you could patch /compiler-rt-$(VERSION).src/lib/msan/CMakeLists.txt in order to generate msan.so when compiling llvm from source (similar as for ASan or UBSan).

Also, I believe there is a mistake in MSan documentation where it's said that static linking with MSan is not supported.

I have situation where I want to use MSan with mixed code (Python->swig.cxx->native.so, as mentioned it is possible for ASan here), I'm using clang 7.0.1 and I keep getting DEADLYSIGNAL from MSan when trying to use it in that way.

Error message:

MemorySanitizer:DEADLYSIGNAL
==17609==ERROR: MemorySanitizer: stack-overflow on address 0x7fffdd85afe8 (pc 0x7fbe5c948e34 bp 0x7fffdd85b050 sp 0x7fffdd85afe0 T17609)
MemorySanitizer:DEADLYSIGNAL
MemorySanitizer: nested bug in the same thread, aborting.

When I'm using ASan in the same way it works as expected.

Kind regards,

Marko Stanojlović

SYRMIA LLC @ Belgrade Office Park
Djordja Stanojevica 12,
Beograd 11070

---

From: Mitch Phillips <mit...@google.com>
Sent: Wednesday, April 7, 2021 9:09 PM
To: Marko Stanojlovic <Marko.St...@syrmia.com>
Cc: llvm...@lists.llvm.org <llvm...@lists.llvm.org>
Subject: Re: [llvm-dev] Using MSan as dso

 

[Mitch Phillips via llvm-dev]

Hi Marko,

> Since MSan is usable as dso it would be very nice if you could patch /compiler-rt-$(VERSION).src/lib/msan/CMakeLists.txt in order to generate msan.so when compiling llvm from source (similar as for ASan or UBSan).

Given that this is a completely-unsupported model, I'd rather not do this.

> Also, I believe there is a mistake in MSan documentation where it's said that static linking with MSan is not supported.

Slightly confusing wording, but the documentation means to say "MSan is not supported for static executables."

> I have situation where I want to use MSan with mixed code (Python->swig.cxx->native.so, as mentioned it is possible for ASan here), I'm using clang 7.0.1 and I keep getting DEADLYSIGNAL from MSan when trying to use it in that way.

I'm sorry - I'm not able to provide much help with this unsupported use case. I'm not surprised things are breaking :(.

[Evgenii Stepanov via llvm-dev]

On Thu, Apr 8, 2021 at 3:01 PM Mitch Phillips <mit...@google.com> wrote:

Hi Marko,

> Since MSan is usable as dso it would be very nice if you could patch /compiler-rt-$(VERSION).src/lib/msan/CMakeLists.txt in order to generate msan.so when compiling llvm from source (similar as for ASan or UBSan).

Given that this is a completely-unsupported model, I'd rather not do this.

I don't mind providing MSan as a shared library (under -shared-libsan), we do the same for other sanitizers and it could be useful for other use cases.

I'm a bit concerned about the extra testing that would require.

But I suspect there may be more problems on your path than you realize. For example, even if you can annotate the entire interface boundary to update MSan shadow state, MSan would still intercept libc calls from uninstrumented code and will expect shadow to be consistent there as well.

Consider building the python interpreter with MSan instead.