On 24-Sep-21 10:52 AM, Olivier Matz wrote:
Hi Zhihong,
On Fri, Sep 24, 2021 at 02:16:29AM +0000, zhihongx.p...@intel.com wrote:
From: Zhihong Peng <zhihongx.p...@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....@intel.com>
Signed-off-by: Zhihong Peng <zhihongx.p...@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
