From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id CCD59A0545;
Wed, 29 Jun 2022 16:59:49 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 826AE40691;
Wed, 29 Jun 2022 16:59:49 +0200 (CEST)
Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com
[209.85.216.47]) by mails.dpdk.org (Postfix) with ESMTP id 7636B400D7
for <dev@dpdk.org>; Wed, 29 Jun 2022 16:59:48 +0200 (CEST)
Received: by mail-pj1-f47.google.com with SMTP id
w19-20020a17090a8a1300b001ec79064d8dso19712284pjn.2
for <dev@dpdk.org>; Wed, 29 Jun 2022 07:59:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=networkplumber-org.20210112.gappssmtp.com; s=20210112;
h=date:from:to:cc:subject:message-id:in-reply-to:references
:mime-version:content-transfer-encoding;
bh=UPvalQwsML7oBW5xPgOLNFpi9eMBBtFkIlYXzfaggLE=;
b=hBM3D6vnNrgQvZIk6wMzs5tpwhqV2uej8XmDpVWD5Jlg3+vUf9evJ2+vCb6mue6DFm
q57+VKK+Mv4uaqeU+Gb8yCR5OBm9QhSdyp5FKxA7QtdqVTNy20L9ksypDeF8K9hweMWb
CYu2QE/1W5lKbyVnrhrQ45kdjB1EHCApklT2YswcUW5yGAwhB6m4YDwvivLAyassKXOE
+Yg8pNLGsQEKq+dNIGNFItKTktFgafuccYWcgAndTxS3Woy7QmRCEvaaPq7IFonmBiCl
GfQiYf1ahLkM9fvcTPmZpKnF2pWAMe1CV96v3ULPSkHgwudfcHhu+yr74GHbqGRNO0Rk
KMmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
:references:mime-version:content-transfer-encoding;
bh=UPvalQwsML7oBW5xPgOLNFpi9eMBBtFkIlYXzfaggLE=;
b=ggSFczn3N7srvMAXS2cV+1s1ZrSkt45RBp9/VbvUDAaqEHFItAFd/dfKGsLrX2O5Sz
3zUTPWkp8wV4+ASbv4pn/8GX7cd+lDqMkKdRPDJvQvmMvrNmT0SmMuoD9YvozNDB45Ma
x8k/FISYhtkC+NzT9EUgXc9zVjYeuoAgcchlf4UTXHIKYNpHjAqGoVW+yjkwPCQWzp2w
JY/InMitNFGX6rJKJMA8PxoIZp82ySeqR6G49fnG/E8bkO4i8SCvo+q6dPu10qJ8pO3C
O1lu+SGrFG8NnF9dFux7IJUocf9SBEHKGcgb4a15SS5beuh572Y1gJFeUi63HM89M5yJ
i6ig==
X-Gm-Message-State: AJIora97RK9KbH+8BbmvJ4vizsp7qRNqtSPEaKfB2yzQ9lOnmCDrXtrN
pQLY8XTOyr+JStP8TazLTX2sd2fkHL9FuXzX
X-Google-Smtp-Source: AGRyM1vIUINm8A67bBUp48x0idpTX73lZrOjJniUy4s9euFr+q+2cWSrpQVNjoUlPdi5ZWYjmQwwNQ==
X-Received: by 2002:a17:902:e881:b0:16a:39e4:c5ef with SMTP id
w1-20020a170902e88100b0016a39e4c5efmr9691107plg.114.1656514787626;
Wed, 29 Jun 2022 07:59:47 -0700 (PDT)
Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199])
by smtp.gmail.com with ESMTPSA id
u10-20020a170902714a00b001693bd7427asm11563774plm.170.2022.06.29.07.59.45
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 29 Jun 2022 07:59:46 -0700 (PDT)
Date: Wed, 29 Jun 2022 07:59:42 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: "halsey.pian@longsys.com" <halsey.pian@longsys.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: DPDK sanitizer seems cannot detect the overflow issue sometimes
Message-ID: <20220629075942.57ee94b0@hermes.local>
In-Reply-To: <95F5C09B652250489A8640C2D0DF5BD0BF99503E@lsex.goodwill-ic.com>
References: <95F5C09B652250489A8640C2D0DF5BD0BF99503E@lsex.goodwill-ic.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
On Wed, 29 Jun 2022 09:56:03 +0000
"halsey.pian@longsys.com" <halsey.pian@longsys.com> wrote:
> Dear All,
>=20
> I would try to detect the illegal memory access issues in my App based on=
DPDK, so I add some codes based on several overflow scenario to check if i=
t is detected in DPDK standalone project.
>=20
> It seems that DPDK santizer cannot find the overflow issue below,
>=20
> I add some code into examples/helloworld/main.c as below,
>=20
> char*p =3D (char*)rte_zmalloc(NULL, 9, 4096);
>=20
> if(p !=3D NULL)
> {
> p =3D p + 32;
> *p =3D 'A=E2=80=98 // should be overflow here
> }
>=20
> But there is no any sanitzer output after dpdk-helloworld exit.
>=20
> BTW, DPDK sanitzer can detect the overflow below,
>=20
>=20
> char*p =3D (char*)rte_zmalloc(NULL, 9, 4096);
>=20
> if(p !=3D NULL)
> {
> p[9] =3D 'A=E2=80=98 // can be detected
> }
>=20
> Unfortunately, DPDK cannot detect the overflow when update the code to be=
low,
> p[32] =3D 'A' // cannot be detected
>=20
>=20
> Version: DPDK 21.11.1
> OS: Fedora 32
> Build: meson setup -Dbuildtype=3Ddebug -Db_lundef=3Dfalse -Db_sanitize=3D=
address -Dexamples=3Dhellowowrld build
>=20
> Is it a known issue? I am confused with this.=20
> Could you provide some info? Thanks.
>=20
> Best Regards
> Halsey Pian
Sorry, it won't work.
There is some integration with Google Address Sanitizer (ASAN) but it does =
not
change the underlying algorithm of how memory is allocated with rte_malloc(=
).
The way ASAN works for regular malloc is that it adds guard regions for each
allocation. That would be very difficult to do with DPDK rte_malloc() which
uses huge pages.
You are better off just using regular malloc in your application unless you
need to use hugepages.