From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 652BF7CBF for ; Thu, 1 Jun 2017 16:24:28 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id b84so160838700wmh.0 for ; Thu, 01 Jun 2017 07:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=Pr7JtJe1q+6myNU54PhFg33nsxf6epiONf6hMMLxvKw=; b=AO+kpq+kPVDkdvRC+tSWLLmrfiPCSM/Px8ad7SeKwGg7j++36G+yONv2wKtiWiMskb yCY2GimEU2gyQGM+Vo+MHMER1RQOdtOnhx3MnU+SRjbV7GnamWoVYJwS2hvO6qRxc3AT xuVEv9FtHuWH/Fa//lgFK3bQUZA29ffJH6PqBfbwfXuHsqQc306sUe+wEWOmzlZSaX98 obOm7+KuSvBHYD42OejuMerTbSz7SAn2w3HDBU6A5hT78a3h2PuPc8JdyNnvfpz0ozjU 6gTaMSD0KyYhiS5CS94BynICjv+Eld5eirtXXf7QHQsJr84U3uxGUZlBxO9RD5Vnud8p ZqeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=Pr7JtJe1q+6myNU54PhFg33nsxf6epiONf6hMMLxvKw=; b=t4CnRDWCehSIhp1cntp+7AL5RYhQjgLQ0/7evRelmJGQJgKJOgE6h4pABjGfNlSEFr h7gQuug2rrwfSYiZsydJ7/fPNcKNo4fffiTHv/dl+prdy4rQmPIStUbKOU2sEvPxajrl 9dItHgND8gKOG878Lfe1BX1HLb66C2QgxfeALtGOaSg2fDi7ANxtw8JfDsipvA81Xu6H /7B1Cax1umCZQddvYQAezeiCyBBvxZzzXw79y3EVONAPOXXs159u9h+jk+HNg5+GX5vT T0R3CJV+/qXQNmLr1swvUpgEmG4MdBsxrGZRXYwPZWqsDqkGoWEy0GDxw9ESFZvVkSLb z4Aw== X-Gm-Message-State: AODbwcCXXvg2xUlGflQJr9inSR1kxewqYBsic7M+AP5fGCneHfPNxEP/ 21SQHrWJhwyBUPF+U+k= X-Received: by 10.223.174.180 with SMTP id y49mr1478072wrc.133.1496327068031; Thu, 01 Jun 2017 07:24:28 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id c8sm18526035wmd.5.2017.06.01.07.24.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Jun 2017 07:24:27 -0700 (PDT) Date: Thu, 1 Jun 2017 16:24:21 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Stephen Hemminger Cc: dev@dpdk.org Message-ID: <20170601142421.GD18840@bidouze.vm.6wind.com> References: <20170531081936.2bbad988@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170531081936.2bbad988@xeon-e3> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v4 06/12] net/failsafe: add flexible device definition 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: , X-List-Received-Date: Thu, 01 Jun 2017 14:24:28 -0000 On Wed, May 31, 2017 at 08:19:36AM -0700, Stephen Hemminger wrote: > On Mon, 29 May 2017 15:42:18 +0200 > Gaetan Rivet wrote: > > > > > +- **exec()** parameter > > + > > + This parameter allows the user to provide a command to the fail-safe PMD to > > + execute and define a sub-device. > > + It is done within a regular shell context. > > + The first line of its output is read by the fail-safe PMD and otherwise > > + interpreted as if passed by the regular **dev** parameter. > > + Any other line is discarded. > > + If the command fail or output an incorrect string, the sub-device is not > > + initialized. > > + All commas within the ``shell command`` are replaced by spaces before > > + executing the command. This helps using scripts to specify devices. > > + > > Exec from a DPDK application seems like possible security hole since most DPDK applications > have to run as root. > > Users will run scripts or other programs that will launch fail-safe instances. If a user launches a script over the fail-safe to configure it or under it to detect devices, security seems at the same level? > > static int > > +fs_execute_cmd(struct sub_device *sdev, char *cmdline) > > +{ > > + FILE *fp; > > + /* store possible newline as well */ > > + char output[DEVARGS_MAXLEN + 1]; > > + size_t len; > > + int old_err; > > + int ret; > > + > > + assert(cmdline != NULL || sdev->cmdline != NULL); > > + if (sdev->cmdline == NULL) { > > + char *new_str; > > + size_t i; > > + > > + len = strlen(cmdline) + 1; > > + new_str = rte_realloc(sdev->cmdline, len, > > + RTE_CACHE_LINE_SIZE); > > + if (new_str == NULL) { > > + ERROR("Command line allocation failed"); > > + return -ENOMEM; > > + } > > Using rte_malloc for cmdline is way over optimizing. rte_malloc comes from huge page area > which is limited. The only reason to use it is if the memory needs to be shared by primary/slave. > Also rte_malloc has much less protection (memleak checkers, guards etc) compared to regular malloc. > I agree, it should be changed. -- Gaëtan Rivet 6WIND