内存分析工具的使用——AddressSanitizer

fpcc

于 2024-10-11 22:20:07 发布

阅读量407

点赞数 9

分类专栏： C++ 文章标签：开发语言 c++

本文链接：https://blog.csdn.net/fpcc/article/details/142864462

版权

C++ 专栏收录该内容

257 篇文章 40 订阅

订阅专栏

一、c/c++中的内存问题

memory corruption，内存崩溃或者说内存损坏。在c/c++程序中，有相当一部分的Bug是由内存引起的，也就是刚刚提到的内存崩溃。说得再通俗一些，往往和内存的非法访问有关。内存问题，轻则导致程序失能，中则导致程序崩溃，重则引起系统瘫痪。
因此，在c/c++编程的过程中，对内存的管理要求非常严格。但灵活多变的指针往往又让很多开发者无法安全的进行内存的处理，即使在新的C++标准中使用了智能指针或者说自行进行了RAII的封装，仍然有可能造成指针引起的内存错误。当然，并不是说c/c++中指针是内存问题的万恶之源，其它情况如数组越界访问等均可以出现类似的问题。
基于上面的内存的问题，很多针对内存进行控制的相关工具也有很多。其中，有静态内存检查工具（Cppcheck等）和动态内存检查工具（valgrind等）。本文介绍一个动态内在检查工具，GAS。

二、GAS

GAS，google address sanitizer，也称为ASan，它是google公司开发的一个快速的内在检测工具。相比于Valgrind对程序的影响，ASan的速度那相当快了。要想监测内存，最好的办法是什么？当然是替换掉编译器的相关内存管理接口了。ASan就提供了一个插桩模块（编译器检测模块LLVM pass）和一个提供malloc等函数替代接口的运行时库。
ASan早期就与LLVM（3.1）进行了结合，将其插桩模块整合到了Clang项目中。后来在Gcc4.8中，也整合了GAS的相关模块，但其配合不太完善，所以推荐使用Gcc4.9以上版本。ASan还有一个专门提供给内核使用的版本KASAN，有兴趣可以搞一下。

三、基本原理

ASan使用的内存检测机制是使用影子内存（shadow memory）来记录当前内存是否可以安全访问的方式。其通过影子内存与常规内存（normal memory）进行映射以期安全的管理内存。通过代码插桩来检查程序运行时影子内存的状态。
当编译器运行时，其通过替代的分配内存管理接口，在内存分配和回收后的区域进行“投毒”(poisoned)，形成所谓的有毒区域（如果有visual studio系列的反汇编的经验会很容易理解这段话，其实就是对内存进行二次标记管理并设置相关的安全管理区域），这个其它的动态内存管理如数组安全检测的机理基本类似。关于影子内存映射的机理和相关细节，请查阅谷歌相关论文，此处不再赘述。

四、ASan支持的内存检查

ASan对常见的内存问题都进行了支持，主要包括下面几点：
1、Use after free
这个比较好理解，它主要是指堆（Heap）内存在释放后又被重新使用。这是一种非常常见的内存问题，类似于下面的代码：

A *a = new A();
delete a;
a->pid = 0;

2、Heap buffer overflow
这也是一种比较常见的内存错误，即堆内存溢出，也就是越界：

char * p = new char[10];
p[11] = 2;

3、Stack buffer overflow
说过了堆溢出怎么能不提栈溢出呢，这个就不举例子了，太简单多见了。
4、Global buffer overflow
全局缓冲区溢出，这都和堆溢出类似。
5、Use after return
返回值使用无效内存，典型的就是返回一个临时变量的指针或引用，看下面的代码：

int * getData(){
  int tmp[10];
  return tmp;
}
int * d = getData();

6、Use after scope
使用作用域外的内存空间，和上面的有些类似。看下面的代码：

for(int i = 0;i< 10;i++){}
int p = i;

7、Initialization order bugs
初始化顺序不同引用的问题，这个比较符合C++的特性。这个在前面的分析过好多次，最典型的就是库中的全局变量与调用者之间调用之间的顺序问题，静态变量也有这种可能的现象。
8、Memory leaks
内存泄露，这可是写c/c++程序员的“亲亲”。不管多么高深的开发者，几乎都会遇到这个问题。但有一句话需要说明：内存泄露不可怕，可怕是内存泄露的累积。

五、应用

在基本了解了ASan后，下面举一个例子来进行实践一把。使用ASan的主要步骤分为：

1、编写测试程序

#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int heapOver() {
  char *pBuf = (char *)malloc(10 * sizeof(char));
  memcpy(pBuf + 10, "abcd1234", 8);
  free(pBuf);

  return 0;
}
int *getData() {
  int *arr = new int[10];
  delete arr;
  return arr;
}
int main() {
  heapOver();
  int arr[10] = {0};
  int d = arr[11];

  int *p = getData();
  delete p;

  return 0;
}

2、在编译时增加相关参数
gcc中增加-fsanitize=address选项；如果想获得较好性能，建议增加-O1或更高编译优化选项;增加fno-omit-frame-pointer选项可以提供更友好的堆栈回溯信息

3、编译并运行：

#编译:注意如果不加-g选项，则无法准确的显示出问题的源码位置，可自行测试一下不带-g
~/project/ASanTest$ g++  -fsanitize=address -fno-omit-frame-pointer -g -o asanTest main.cpp
#运行
~/project/ASanTest$ ./asanTest 
=================================================================
==94673==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000001a at pc 0x7f6acbe3a2c3 bp 0x7ffde51ff060 sp 0x7ffde51fe808
WRITE of size 8 at 0x60200000001a thread T0
    #0 0x7f6acbe3a2c2 in __interceptor_memcpy ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
    #1 0x55b7993f9381 in heapOver() /home/qt65_project/ASanTest/main.cpp:8
    #2 0x55b7993f9477 in main /home/fqt65_project/ASanTest/main.cpp:19
    #3 0x7f6acb629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #4 0x7f6acb629e3f in __libc_start_main_impl ../csu/libc-start.c:392
    #5 0x55b7993f9284 in _start (/home//qt65_project/ASanTest/asanTest+0x1284)

0x60200000001a is located 0 bytes to the right of 10-byte region [0x602000000010,0x60200000001a)
allocated by thread T0 here:
    #0 0x7f6acbeb4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x55b7993f935e in heapOver() /home/qt65_project/ASanTest/main.cpp:7
    #2 0x55b7993f9477 in main /home/fqt65_project/ASanTest/main.cpp:19
    #3 0x7f6acb629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: heap-buffer-overflow ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827 in __interceptor_memcpy
Shadow bytes around the buggy address:
  0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c047fff8000: fa fa 00[02]fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==94673==ABORTING

大家可以依次的进行测试，就会将三种类型的问题，都在运行时暴露出来。分别报得错误是“堆溢出、栈溢出和分配释放不匹配”。而且描述的非常详细和准确，大家可以自己动手实践一把。