[dpdk-dev] [PATCH v4 1/2] Enable ASan for memory detector on DPDK

[Burakov, Anatoly]

On 24-Sep-21 10:52 AM, Olivier Matz wrote:
> Hi Zhihong,
> 
> On Fri, Sep 24, 2021 at 02:16:29AM +0000, zhihongx.peng at intel.com wrote:
>> From: Zhihong Peng <zhihongx.peng at intel.com>
>>
>> AddressSanitizer (ASan) is a google memory error detect
>> standard tool. It could help to detect use-after-free and
>> {heap,stack,global}-buffer overflow bugs in C/C++ programs,
>> print detailed error information when error happens, large
>> improve debug efficiency.
>>
>> By referring to its implementation algorithm
>> (https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm),
>> enable heap-buffer-overflow and use-after-free functions on dpdk.
>> DPDK ASan function currently only supports on Linux x86_64.
>> Support other platforms, need to define ASAN_SHADOW_OFFSET value according
>> to google ASan document.
>>
>> Here is an example of heap-buffer-overflow bug:
>>          ......
>>          char *p = rte_zmalloc(NULL, 7, 0);
>>          p[7] = 'a';
>>          ......
>>
>> Here is an example of use-after-free bug:
>>          ......
>>          char *p = rte_zmalloc(NULL, 7, 0);
>>          rte_free(p);
>>          *p = 'a';
>>          ......
>>
>> If you want to use this feature,
>> you need to add below compilation options when compiling code:
>> -Dbuildtype=debug -Db_lundef=false -Db_sanitize=address
>> "-Dbuildtype=debug": This is a non-essential option. When this option
>> is added, if a memory error occurs, ASan can clearly show where the
>> code is wrong.
>> "-Db_lundef=false": When use clang to compile DPDK, this option must
>> be added.
>>
>> Note:
>> a) The issue of ASan wild pointer is that dpdk ASan tool is not fully
>> adapted to google ASan. For example: Address 0x7fe2ffafa240 is a wild
>> pointer.
>> b) Centos needs to install libasan separately.
>> c) If the program uses DPDK cmdline, when a memory bug occurs, need
>> to execute the "stty echo" command.
>>
>> Signed-off-by: Xueqin Lin <xueqin.lin at intel.com>
>> Signed-off-by: Zhihong Peng <zhihongx.peng at intel.com>
> 
> Thank you for this patch, this looks quite useful.
> 
> Do you know what is the performance impact of enabling ASan?
> 
> Do you think a similar approach could be applied to mempools?

It would be a bit difficult, because mempools aren't actually allocating 
anything, they're just juggling pointers. A lot of times, an "allocated" 
mbuf wouldn't actually be allocated, and just sitting in the mempool 
cache, being "free" while still not present in the mempool.

Also, obviously, any such functionality (be it ASan for rte_malloc, or 
ASan for mempools) will necessarily only work inside one process, and 
will not support multiprocess.

> 
> Regards,
> Olivier
> 


-- 
Thanks,
Anatoly