From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v4 0/2] Add support for driver directories Date: Thu, 03 Dec 2015 03:26:40 +0100 Message-ID: <4326350.y6KGzOFPTo@xps13> References: <5394034.PY3UYPlQag@xps13> <20151202180702.784048ca@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: Stephen Hemminger Return-path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id CFA488D86 for ; Thu, 3 Dec 2015 03:27:50 +0100 (CET) Received: by wmww144 with SMTP id w144so3554259wmw.0 for ; Wed, 02 Dec 2015 18:27:50 -0800 (PST) In-Reply-To: <20151202180702.784048ca@xeon-e3> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2015-12-02 18:07, Stephen Hemminger: > On Thu, 12 Nov 2015 16:52:32 +0100 > Thomas Monjalon wrote: > > > > > This mini-series adds support for driver directory concept > > > > based on idea by Thomas Monjalon back in February: > > > > http://dpdk.org/ml/archives/dev/2015-February/013285.html > > > > > > > > In the process FreeBSD also gains plugin support (but untested). > > > > > > > > v4: - introduce error-early behavior for invalid plugin paths > > > > - support directories via the existing -d option instead of adding new > > > > > > > > v3: - merge the first commits > > > > > > > > v2: - move code to eal/common > > > > - add bsd support > > > > > > > > Panu Matilainen (2): > > > > eal: move plugin loading to eal/common > > > > eal: add support for driver directory concept > > > > > > > > > checkpatch complains for some indent problem (Thomas, can you fix this ?), > > > but the rest looks good to me. > > > > > > Acked-by: David Marchand > > > > > > Thanks Panu. > > > > Applied, thanks > > This patch introduces a new issue reported by Coverity. > > The root cause of the problem is that you are checking that it s a directory first with stat > then calling dlopen(). I malicious entity could get between the stat and the dlopen. I think it is a false positive. The aim of loading every files in the directory is out of a security scope IMHO.