For Android app developers, the development ecosystem offers a number of components among which Android sanitizers are one most important. Other important components that are also used frequently are AddressSanitizers, SanitizerCoverage, and UndefinedBehaviourSanitizer. Being compiler based sanitizer, these components are exceptional to use for testing and development purposes in order to clean out the bugs. This helps make Android ecosystem work in a much better manner. The Android has presently got the support of sanitizers that are exceptional to be used for diagnosing memory bugs. This write-up will talk about the above-mentioned Android sanitizers in detail to give the actual impression on how these elements work. Keep on reading to know how these systems can be used to empower the Android build up system.
Being a compiler based component, AddressSanitizer (ASan) is a tool to perfectly detect the runtime of different types of memory errors in C and C++ code. In Android, following classes of memory have been tested:
- Out-of-bounds accesses to heap, stack, and globals
- Use-after-return (runtime flagASAN_OPTIONS=detect_stack_use_after_return=1)
- Use-after-scope (clang flag -fsanitize-address-use-after-scope)
- Double-free, invalid free
UndefinedBehaviourSanitizer or UBSan
UndefinedBehaviourSanitizer or UBSan is used to check different types of undefined behavior. In case, device manufacturers wish to include the same in their test builds, they can do it through LOCAL_SANITIZE:=default-ub in their makefiles or default-ub: true in the sanitize block of blueprint files. While UndefinedBehaviourSanitizer or UBSan has been designed specifically for identifying undefined behaviors, the Android originally supports:
With SanitizerCoverage, the code coverage can be used at different levels including call level, basic block level or edge level. These codes can be used alone or in conjunction with the Android sanitizers like UndefinedBehaviourSanitizer i.e. UBSan and AddressSanitizer. Additionally, in order to use the guard-based coverage, the settings can be set as fsanitize-coverage=trace-pc-guard. This initiates the compiler to embed the setting as: sanitizer_cov_trace_pc_guard(&guard_variable) on particular edge. Each edge has its own uint32_t guard_variable. In addition, a module constructor, __sanitizer_cov_trace_pc_guard_init(uint32_t* start, uint32_t* stop) is also generated. All the __sanitizer_cov_ functions are important to be provided by the user.
In addition to this, SanitizerCoverage can also be used for data coverage. The activation goes with fsanitize-coverage=trace-cmp and the changes are implemented with __sanitizer_cov_trace_* functions. The given functionalities are similar for integer division and GEP instructions activated with fsanitize-coverage=trace-div and fsanitize-coverage=trace-gep respectively.
Additionally, there are two different files namely .sancov file, and a sancov.map file wherein the information is recorded during a coverage sanitizer session. .sancov file has all the information related to instrumented points in the program and the second file has execution trace that is represented as a sequence in the first file. And, the default setting of these files is the current working directory.
This Article is Originally published here.