From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by dpdk.org (Postfix) with ESMTP id 43759B3AD for ; Mon, 8 Sep 2014 14:35:34 +0200 (CEST) Received: by mail-pa0-f52.google.com with SMTP id eu11so27261437pac.25 for ; Mon, 08 Sep 2014 05:40:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gNuZ7HkXTGXUDoQDBgC+aygpbt8nxzbIegnNauZD8AE=; b=UvU7hJrEGUw7YHMjSjiQkim1NjSjTGgvwP1w8hTSLcJW3Fn7TzaUTsWlfj41Tky18w j2aO65ATVvDRlWYIc4R0ATRZHR7QvOuphRYhDbBoA8+IwAAl1iF1cCJG3n+T/XxORTSy vlsgK2j+1JtlcGG0ul4gvrbwBXafY+XgQPNZWjpn8ob3erDQQroQyBUZnxjGW3gu1J59 WNCClJtlIa5ZB6Rcy89sFkzAhzayNjWGQTcs1us8+RMkhiA9KCZD3OIA7hxO7RLK74oE zgLuowbZN4RjPYpkCJva/SC8rvCsxZdZCKH34j12KpLgnSTuYmcVbvye/itpicTLRcrF UvTg== X-Gm-Message-State: ALoCoQmQNA1mMZAE6vYtK6laquqwbakJxBpbb0UKognrJQdy23g6USK9V8ts4OvzAF6/yCBLZkZU MIME-Version: 1.0 X-Received: by 10.66.243.208 with SMTP id xa16mr45613316pac.41.1410180033073; Mon, 08 Sep 2014 05:40:33 -0700 (PDT) Received: by 10.70.44.135 with HTTP; Mon, 8 Sep 2014 05:40:32 -0700 (PDT) In-Reply-To: <59AF69C657FD0841A61C55336867B5B0343EF596@IRSMSX103.ger.corp.intel.com> References: <59AF69C657FD0841A61C55336867B5B0343EF596@IRSMSX103.ger.corp.intel.com> Date: Mon, 8 Sep 2014 07:40:32 -0500 Message-ID: From: Matt Laswell To: "Richardson, Bruce" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Question about ASLR X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 12:35:34 -0000 Bruce, That's tremendously helpful. Thanks for the information. -- Matt Laswell *infinite io* On Sun, Sep 7, 2014 at 2:52 PM, Richardson, Bruce < bruce.richardson@intel.com> wrote: > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Matt Laswell > > Sent: Friday, September 05, 2014 7:57 PM > > To: dev@dpdk.org > > Subject: [dpdk-dev] Question about ASLR > > > > Hey Folks, > > > > A colleague noticed warnings in section 23.3 of the programmer's guide > > about the use of address space layout randomization with multiprocess > DPDK > > applications. And, upon inspection, it appears that ASLR is enabled on > our > > target systems. We've never seen a problem that we could trace back to > > ASLR, and we've never see a warning during EAL memory initialiization, > > either, which is strange. > > > > Given the choice, we would prefer to keep ASLR for security reasons. > Given > > that in our problem domain: > > - We are running a multiprocess DPDK application > > - We run only one DPDK application, which is a single compiled binary > > - We have exactly one process running per logical core > > - We're OK with interrupts coming just to the primary > > - We handle interaction from our control plane via a separate shared > > memory space > > > > Is it OK in this circumstance to leave ASLR enabled? I think it probably > > is, but would love to hear reasons why not and/or pitfalls that we need > to > > avoid. > > > > Thanks in advance. > > > > -- > > Matt Laswell > > *infinite io* > > Having ASLR enabled will just introduce a small element of uncertainty in > the application startup process as you the memory mappings used by your app > will move about from run to run. In certain cases we've seen some of the > secondary multi-process application examples fail to start at random once > every few hundred times (IIRC correctly - this was some time back). > Presumably the chances of the secondary failing to start will vary > depending on how ASLR has adjusted the memory mappings in the primary. > So, with ASLR on, we've found occasionally that mappings will fail, in > which case the solution is really just to retry the app again and ASLR will > re-randomise it differently and it will likely start. Disabling ASLR gives > repeatability in this regard - your app will always start successfully - or > if there is something blocking the memory maps from being replicated - > always fail to start (in which case you try passing EAL parameters to hint > the primary process to use different mapping addresses). > > In your case, you are not seeing any problems thus far, so likely if > secondary process startup failures do occur, they should hopefully work > fine by just trying again! Whether this element of uncertainty is > acceptable or not is your choice :-). One thing you could try, to find out > what the issues might be with your app, is to just try running it > repeatedly in a script, killing it after a couple of seconds. This should > tell you how often, if ever, initialization failures are to be expected > when using ASLR. > > Hope this helps, > Regards, > /Bruce >