DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Lin, Xueqin" <xueqin.lin@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
	"Peng, ZhihongX" <zhihongx.peng@intel.com>
Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC] porting AddressSanitizer feature to DPDK
Date: Fri, 11 Jun 2021 06:15:05 +0000	[thread overview]
Message-ID: <BN7PR11MB2658935E8C1B2FF53DF17AD494349@BN7PR11MB2658.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20210610130311.57f5dbfb@hermes.local>

> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Friday, June 11, 2021 4:03 AM
> To: Peng, ZhihongX <zhihongx.peng@intel.com>
> Cc: Burakov, Anatoly <anatoly.burakov@intel.com>; dev@dpdk.org; Lin,
> Xueqin <xueqin.lin@intel.com>
> Subject: Re: [RFC] porting AddressSanitizer feature to DPDK
> 
> On Thu, 10 Jun 2021 13:13:52 +0800
> zhihongx.peng@intel.com wrote:
> 
> > From: Zhihong Peng <zhihongx.peng@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),
> > ported heap-buffer-overflow and use-after-freefunctions to dpdk.
> >
> > 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 use the following compilation options:
> > -Dc_args='-DRTE_MALLOC_ASAN'
> > -Db_lundef=false -Db_sanitize=address
> >
> > Signed-off-by: Xueqin Lin <xueqin.lin@intel.com>
> > Signed-off-by: Zhihong Peng <zhihongx.peng@intel.com>
> > ---
> >  lib/eal/common/malloc_elem.c |  33 +++++++-
> > lib/eal/common/malloc_elem.h | 141
> ++++++++++++++++++++++++++++++++++-
> >  lib/eal/common/malloc_heap.c |  19 +++++
> >  lib/eal/common/rte_malloc.c  |   6 ++
> >  4 files changed, 197 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/eal/common/malloc_elem.c
> > b/lib/eal/common/malloc_elem.c index c2c9461f1..4a146b1b9 100644
> > --- a/lib/eal/common/malloc_elem.c
> > +++ b/lib/eal/common/malloc_elem.c
> > @@ -446,6 +446,9 @@ malloc_elem_alloc(struct malloc_elem *elem,
> size_t size, unsigned align,
> >  		struct malloc_elem *new_free_elem =
> >  				RTE_PTR_ADD(new_elem, size +
> MALLOC_ELEM_OVERHEAD);
> >
> > +#ifdef RTE_MALLOC_ASAN
> > +		asan_clear_split_alloczone(new_free_elem);
> > +#endif
> 
> 
> Two things:
> ASAN should be detected using standard compiler flags, not a DPDK option.
> GCC uses __SANITIZE_ADDRESS__ and Clang uses feature macro.

Thanks Stephen for your review and suggestion, we will improve this part.
Only use Asan standard compiler flags, remove DPDK option for the tool detect.
 
> 
> Rather than littering DPDK code with ifdefs' a better method is to do define
> stub inline (or macros if you insist) in the header file.
Good capture, we will improve it in V2.
> 


  reply	other threads:[~2021-06-11  6:15 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-10  5:13 zhihongx.peng
2021-06-10  8:32 ` Bruce Richardson
2021-06-11  4:42   ` Lin, Xueqin
2021-06-10  9:12 ` Ananyev, Konstantin
2021-06-11  4:49   ` Lin, Xueqin
2021-06-10 20:03 ` Stephen Hemminger
2021-06-11  6:15   ` Lin, Xueqin [this message]
2021-06-15  8:12 ` [dpdk-dev] [RFC v2] " zhihongx.peng
2021-06-15  8:40   ` Jerin Jacob
2021-06-16  9:13     ` Lin, Xueqin
2021-06-16 11:34       ` Jerin Jacob
2021-06-18  7:48         ` Lin, Xueqin
2021-06-18  9:04           ` David Marchand
2021-06-22  3:26             ` Lin, Xueqin
2021-06-28 14:22             ` Burakov, Anatoly
2021-06-28 14:23               ` Jerin Jacob
2021-06-30  8:15               ` Lin, Xueqin
2021-06-30  8:34               ` David Marchand
2021-07-01  6:48                 ` Lin, Xueqin
2021-07-01  7:40                   ` David Marchand
2021-07-02 11:05                     ` Lin, Xueqin
2021-07-06 20:40   ` David Christensen
2021-07-06 23:12     ` Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BN7PR11MB2658935E8C1B2FF53DF17AD494349@BN7PR11MB2658.namprd11.prod.outlook.com \
    --to=xueqin.lin@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.org \
    --cc=zhihongx.peng@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).