Developers Blog Insight: Know About Android Sanitizers

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.

AddressSanitizer

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-free

• 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

AddressSanitizer has got support from two high-level components. One includes memory-related functional calls, such as alloca, malloc, and free that have information in order to track memory allocation, and usage statics. This helps (ASan) to identify memory usages bugs such as use-after scope, free, return as well as double-free. ASan makes use of shadow memory to identify which memory type is completely poisoned or completely normal.

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:

• bool

• Integer-divide-by-zero

• Return

• Returns-nonnull-attribute

• Shift-exponent

• Unreachable

• Vla-bound

The Android build system also uses UBSan’s integer overflow checking. The instrument also provides support to unsigned-integer-overflow. This is not a technically undefined behavior but it is still counted in the sanitizer. They can easily be included in makefiles by arranging the setting LOCAL_SANITIZE in order to signed-integer-overflow, unsigned-integer-overflow, or the combination flag integer. This setting enables the setting: signed-integer-overflow, unsigned-integer-overflow, integer-divided-by-zero, shift-exponent and shift-base. The setting can also be enabled in blueprint files by enabling Misc_undefines to the required flag.

SanitizerCoverage

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.