From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Wed, 29 Jun 2022 16:59:48 +0200 (CEST) Received: by mail-pj1-f47.google.com with SMTP id w19-20020a17090a8a1300b001ec79064d8dso19712284pjn.2 for ; 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 To: "halsey.pian@longsys.com" Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, 29 Jun 2022 09:56:03 +0000 "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.