On Fri, 24 Sep 2021 11:52:33 +0200
Olivier Matz <olivier.m...@6wind.com> 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?
Purely application dependent. In the Linux kernel on x86 it is around
10% according to report by Google. My observation is that for DPDK
(for malloc/free etc, not this patch) ASAN causes large impact
on Arm like 90% slower. But our application is CPU intensive.
> Do you think a similar approach could be applied to mempools?
