Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Need instrumented versions for system libs to make MSAN work #608
I've looked at the existing warnings from libpng, freetype, libarchive,
So, I think any further msan roll up is blocked until we can provide msan-instrumented libs in the docker image for msan.
I suggest this order of steps:
We now have a set of scripts in https://github.com/google/oss-fuzz/tree/master/infra/base-images/msan-builder that attempt to build MSan instrumented libraries by hooking into debian's package build system.
This should hopefully work for most packages in a debian-based distro with some minor overrides.
At at high level this:
Our infra will build a set of libraries specified here
Some remaining work:
Having just one module built with -fsanitize-recover=memory will flip the default setting of halt_on_error in MSAN_OPTIONS to false, which will make all reports in interceptors non-terminating. Even when the interceptor is called from a module that is built w/o fsanitize-recover. You can compensate for that by setting MSAN_OPTIONS=halt_on_error=true.…
On Thu, Dec 7, 2017 at 10:05 AM, Oliver Chang ***@***.***> wrote: Also have a question for @eugenis <https://github.com/eugenis> : To keep our build process simple, we're building libraries with -fsanitize-recover=memory. Are there any downsides to this? And can we mix a binary compiled *without* -fsanitize-recover=memory with these libraries? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#608 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZuSoEQ8FrbNeWPFzjr2hCMjLomTxSBks5s-CkHgaJpZM4NaotU> .
added a commit
Jan 11, 2018
Progress update. MSan builds will now use static libraries available in this list. Builds will also have their rpaths patched to use any instrumented dynamic libraries available too.
2 projects I looked at: