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
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 annotateevery 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.
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
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 :(.
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.