From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 864B6A04C1; Thu, 21 Nov 2019 22:17:09 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3A8A52BA3; Thu, 21 Nov 2019 22:17:08 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 47E0E91 for ; Thu, 21 Nov 2019 22:17:06 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D7A03223E4; Thu, 21 Nov 2019 16:17:05 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 21 Nov 2019 16:17:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=KdQqYBNWD76PMyJPNUpxegAotuBFKYy4bqN7e6v7SJ0=; b=SaDmoM1QFYIc 0OXTUSGKsFjXATGHhpPLU484LGwDe7GJ8PKaEh3nf8RqCGVCQOA1c1BQHeYefAVv Wa4S47ElNNgILIHdJJMpkdz9asvbLJj1X95dsL2EhdzvDPbK/tmUFMv74gfRvE7X aUQ+Kudab/OGkvFTOju8TcGqvPxXPpw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=KdQqYBNWD76PMyJPNUpxegAotuBFKYy4bqN7e6v7S J0=; b=wEPLkMV/iiFjsTJv3chIPf+HrQ8kHBh9v/fq+v7YzcxOFcXKiqahF7Jsr Jap9ihBNuV6eLNie7kQnZSOTLC86B6ZIcFCRYKglTmqcraPtAexmdXUp+seF7v5X kJR7z2z9Xtkdky8lB0sj6uEatmZ9Y9zafXLWkngt/0fslFmlmfN3ejQ3P957HtH0 b8hr0PAg0I2RTvRMeALOBlBZiJlN+r+gTPvulXAqcddenkgKZsvlLkYmqhchFmdh 8hMHl5C0E5S2AdEQfy/cUm9ncPZ0aZYm+bOuj7lFr+LaguiBljmWmhiVoXPm+HkV H0pAfsiS8cESKyHKqEXhRsNHpe4Mg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehvddgudegkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc fkphepjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpeht hhhomhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id A683580064; Thu, 21 Nov 2019 16:17:04 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit Cc: Andrew Rybchenko , dev@dpdk.org, Bruce Richardson , david.marchand@redhat.com Date: Thu, 21 Nov 2019 22:17:03 +0100 Message-ID: <3174926.22sA95HNGQ@xps> In-Reply-To: <5b9ae095-6926-b67a-6368-29db57782213@intel.com> References: <20191112131556.16668-1-ferruh.yigit@intel.com> <3766664.SyXFxqzVBa@xps> <5b9ae095-6926-b67a-6368-29db57782213@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] mk: remove library search path from binary X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 21/11/2019 18:12, Ferruh Yigit: > On 11/18/2019 3:14 PM, Thomas Monjalon wrote: > > 12/11/2019 14:15, Ferruh Yigit: > >> This patch functionally reverts the patch in fixes line to not have any > >> hardcoded library path in the final binary for the security reasons, in > >> case this binary distributed to production environment. > > > > What about meson? > > There are these rpaths: > > $ORIGIN/../lib > > $ORIGIN/../drivers > > > > > >> RPATH only added in RTE_DEVEL_BUILD case and this binary shouldn't > >> distributed, but still removing it to be cautious. > > > > For convenience, we could keep adding rpath for internal apps. > > This was the main intention, but the concern is someone unaware of this > capability and distributes a binary that we think it will be internal. Internal apps are only for developers. I don't see how there could be a security issue. > >> --- a/devtools/test-null.sh > >> +++ b/devtools/test-null.sh > > > >> if ldd $testpmd | grep -q librte_ ; then > >> + export LD_LIBRARY_PATH=$build/lib:$LD_LIBRARY_PATH > >> libs='-d librte_mempool_ring.so -d librte_pmd_null.so' > > > > > > There is an issue in this change, because $build may be undefined. > > It can be fixed with adding this line: > > > > +[ -f "$testpmd" ] && build=$(dirname $(dirname $testpmd)) > > [ -f "$testpmd" ] || testpmd=$build/app/dpdk-testpmd > > [ -f "$testpmd" ] || testpmd=$build/app/testpmd > > 'build' is already defined as following at the beginning of the script > build=${1:-build} Yes, but $1 can be the testpmd path as well, so $build is meaningless. > And if 'build' is wrong/missing, script can't reach to this line at all, because > 'testpmd' path found based on 'build' and if 'testpmd' not found, script will exit. No, $testpmd can be defined from $1, not based on $build. You missed this comment: build=${1:-build} # first argument can be the build directory testpmd=$1 # or first argument can be the testpmd path > Can you please give more detail what is problem with 'build'? If the testpmd path is directly passed as first parameter, build directory is not known. That's why I suggest getting it with $(dirname $(dirname $testpmd)).