AddressSanitizer

AddressSanitizer (ASan) 是一种基于编译器的快速检测工具,用于检测原生代码中的内存错误。

Android Q 和 AArch64 上的 AOSP master 分支支持硬件加速 ASan (HWASan),这是一种 RAM 开销更小、检测到的错误范围更大的类似工具。

AddressSanitizer 可以检测以下问题:

  • 堆栈和堆缓冲区上溢/下溢
  • 释放之后的堆使用情况
  • 超出范围的堆栈使用情况
  • 重复释放/错误释放

除了 AddressSanitizer 可以检测到的错误之外,HWASan 还可以检测返回之后的堆栈使用情况。

ASan 可同时在 32 位和 64 位 ARM 以及 x86 和 x86-64 上运行。ASan 的 CPU 开销约为 2 倍,代码大小开销在一半到 2 倍之间,并且内存开销很大(具体取决于您的分配模式,但约为 2 倍)。

HWASan 具有类似的 CPU 和代码大小开销,但 RAM 开销要小得多 (15%)。HWASan 具有不确定性。只有 256 个可能的标记值,因此忽略任何错误的概率为 0.4%。ASan 对检测上溢规定了有限大小的 redzone,并对检测释放后使用情况规定了有限容量隔离区,而 HWAsan 没有这些规定,因此上溢大小或多久之前内存解除分配对 HWAsan 无关紧要。这使得 HWASan 优于 ASan。您可以详细了解 HWAsan 的设计Android 上的 HWASan 的使用。

Valgrind 的 Memcheck 工具类似,但除了堆上溢外,ASan 还能检测堆栈/全局上溢,并且速度快多了,内存开销更少。相反,Valgrind 可检测未初始化的读取和内存泄露(而 ASO 不能)。Valgrind 可能对调试应用很有用,但对整个操作系统来说并不实用,这就是 Android 团队改用 ASan 的原因。

本文档介绍了如何使用 AddressSanitizer 编译和运行 Android 操作系统自身的各个/所有组成部分。如果要使用 AddressSanitizer 编译 SDK/NDK 应用,请参阅 AddressSanitizerOnAndroid

使用 ASan 清理各个可执行文件

LOCAL_SANITIZE:=addresssanitize: { address: true } 添加到可执行文件的编译规则中。您可以搜索现有示例的代码或查找其他可用的排错程序。

检测到错误时,ASan 会向标准输出和 logcat 发送一份详细报告,然后让进程崩溃。

使用 ASan 清理共享库

根据 ASan 的工作原理,不是通过 ASan 编译的可执行文件将无法使用通过 ASan 编译的库。

注意:在运行时,如果将 ASan 库加载到错误的进程中,系统将显示以 _asan_sanitizer 开头的消息,提示您有无法解析的符号。

要对多个可执行文件(并非所有这些可执行文件都是使用 ASan 编译的)使用的共享库进行测试,您需要该库的 2 个副本。为此,建议您针对相应的模块向 Android.mk 中添加以下内容:

LOCAL_SANITIZE:=address
LOCAL_MODULE_RELATIVE_PATH := asan

这样一来,系统会将库放置到 /system/lib/asan(而非 /system/lib)中。然后,使用以下方法运行您的可执行文件:LD_LIBRARY_PATH=/system/lib/asan

对于系统守护程序,将以下内容添加到 /init.rc/init.$device$.rc 的相应部分。

setenv LD_LIBRARY_PATH /system/lib/asan

警告LOCAL_MODULE_RELATIVE_PATH 设置会将您的库移至 /system/lib/asan,这意味着,如果从头开始重写并重新编译,将会导致 /system/lib 中缺少该库,并且生成的映像可能无法启动。这是当前编译系统存在的一个令人遗憾的限制。请不要重写;而是执行 make -j $Nadb sync

通过读取 /proc/$PID/maps,验证相应进程使用的库是否来自 /system/lib/asan(如果此库存在)。如果不是,您可能需要停用 SELinux,如下所示:

adb root
adb shell setenforce 0
# restart the process with adb shell kill $PID
# if it is a system service, or may be adb shell stop; adb shell start.

更出色的堆栈跟踪

AddressSanitizer 使用基于帧指针的快速展开程序 (unwinder),根据程序中的每个内存分配和取消分配事件来记录堆栈跟踪信息。Android 的大部分组件都未使用帧指针进行编译。因此,您通常仅会获得 1 个或 2 个有意义的帧。要解决此问题,请使用 ASan(推荐)或以下选项重新编译库:

LOCAL_CFLAGS:=-fno-omit-frame-pointer
LOCAL_ARM_MODE:=arm

或者在进程环境中设置 ASAN_OPTIONS=fast_unwind_on_malloc=0。后者可能对 CPU 要求极高,具体取决于负载。

符号化

最初,ASan 报告中包含对二进制文件和共享库中的偏移量的引用。您可以通过以下两种方法获取源文件和行信息:

  • 确保 /system/bin 中有 llvm-symbolizer 二进制文件。Llvm-symbolizer 根据 third_party/llvm/tools/llvm-symbolizer 中的源文件进行编译
  • 通过 external/compiler-rt/lib/asan/scripts/symbolize.py 脚本过滤报告。

由于可以使用主机上的符号化库,因此第二种方法可以提供更多数据(即 file:line 位置)。

在应用中使用 AddressSanitizer

AddressSanitizer 无法检查 Java 代码,但可以检测 JNI 库中的错误。为此,您需要使用 ASan 编译可执行文件(在此情况下是 /system/bin/app_process(32|64))。这将在设备上的所有应用中同时启用 ASan,因而会给设备带来一些压力,但 2GB RAM 的设备可以从容处理这种情况。

LOCAL_SANITIZE:=address 中的 app_process 编译规则添加常规的 frameworks/base/cmds/app_process。暂时忽略同一个文件中的 app_process__asan 目标(如果在您阅读本文时这个目标仍存在于其中)。在 system/core/rootdir/init.zygote(32|64).rc 中修改 Zygote 记录,以添加以下行:

setenv LD_LIBRARY_PATH /system/lib/asan:/system/lib
setenv ASAN_OPTIONS
allow_user_segv_handler=true

编译,然后依次执行以下命令:adb sync、fastboot flash boot、reboot。

使用 wrap 属性

上一部分中的方法将 AddressSanitizer 放置到了系统的每个应用中(实际上是放置到了 Zygote 进程的每个子项中)。您可以只通过 ASan 运行一个或少数几个应用,从而节省一些内存空间,但是应用启动速度会变慢。

为实现这一目标,您可以通过“wrap.”属性(与在 Valgrind 下运行应用时所用的属性相同)启动应用。下面是在 ASan 下运行 Gmail 应用的示例:

adb root
adb shell setenforce 0  # disable SELinux
adb shell setprop wrap.com.google.android.gm "asanwrapper"

在此情况下,asanwrapper 会将 /system/bin/app_process 重写至(使用 AddressSanitizer 编译的)/system/bin/asan/app_process。此外,它还会在动态库搜索路径的开头处添加 /system/lib/asan。这样一来,通过 asanwrapper 运行应用时,系统会优先使用 /system/lib/asan 中可通过 ASan 进行测试的库,而非 /system/lib 中的普通库。

同样,如果发现错误,应用会崩溃,且系统会将报告记录到日志中。

SANITIZE_TARGET

自 Android 7.0 Nougat 起,系统支持使用 ASan 一次性编译整个 Android 平台。(如果您要编译的版本比 Android 9.0 Pie 更高,那么 HWASan 是更好的选择。)

在同一编译树中运行以下命令。

make -j42
SANITIZE_TARGET=address make -j42

在此模式下,userdata.img 中包含其他库,必须也刷写到设备上。请使用以下命令行:

fastboot flash userdata && fastboot flashall

其工作原理是编译两组共享库:/system/lib 中的常规库(第一次 make 调用),/data/asan/lib 中进行 ASan 插桩的库(第二次 make 调用)。第二次编译出的可执行文件会覆盖第一次编译出的可执行文件。通过使用 PT_INTERP 中的“/system/bin/linker_asan”,可通过 ASan 进行测试的可执行文件会获得一个不同的库搜索路径(在该路径中,/data/asan/lib 前面添加了 /system/lib)。

$SANITIZE_TARGET 的值变更时,编译系统会重写中间对象目录。这样一来,系统便会强制重新编译所有目标,同时保留 /system/lib 下已安装的二进制文件。

以下目标不能使用 ASan 进行编译:

  • 静态关联的可执行文件。
  • LOCAL_CLANG:=false 目标
  • 不会针对 SANITIZE_TARGET=address 进行 ASan 操作的 LOCAL_SANITIZE:=false

在 SANITIZE_TARGET 编译中,系统会跳过此类可执行文件,且会将第一次 make 调用中编译的版本留在 /system/bin 中。

此类库只是未使用 ASan 进行编译,但它们仍然可包含来自其依赖的静态库的 ASan 代码。

支持文档

AddressSanitizerOnAndroid 公共项目网站

AddressSanitizer 和 Chromium

其他 Google 排错程序