We work on sanitization of whole Tizen OS and therefore try to cover as many code as we can with Address Sanitizer.

Currently we came to sanitization of native libraries which are used only by managed applications running on CoreCLR.

Currently we have setup of two parts:

1. Additional build of patched Address Sanitizer run-time with "switchable" interceptors.

2. Patched CoreCLR version with changed native calls generation behavior.

Address Sanitizer patch is required to add additional API to activate or deactivate ASan interception of library calls (e.g. tracing malloc()/free()) in order to get appropriate performance of CoreCLR engine and to avoid reports about CoreCLR internals' issues: our primary customer wants to get reports about their code only, CoreCLR testing is a separate task. Additional build is required since this API introduces a performance overhead to each library call, which we don't want to see for the rest of applications.

CoreCLR version has changes in JIT part in generator of calls from managed code to native libraries, a wrapper is added which calls ASan API to switch tracing on when code from library is executed and turn it off during return back to managed code.

Now we only detect issues inside native libraries, but our next target is annotate CoreCLR allocator, integrate it with ASan and catch bugs for cases when buffer allocated by managed code is passed to native library and corrupted there. Accordingly to our customers, who develop apps for Tizen, this case is rather hard to debug and consequences of such errors are rather bad.

Currently we use GCC to build Tizen OS, so our changes are introduced only to GCC ASan run-time inside libasan.so. Technically it's possible to add it to Clang run-time as well, but it'll require recompilation of target libraries since Clang ASan uses static linkage and we're not sure that someone really needs this support. If you are interested in this kind of testing as well, we could introduce this mode in a conditional build.

cc @alpencolt