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 at intel.com> wrote: > > -----Original Message----- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matt Laswell > > Sent: Friday, September 05, 2014 7:57 PM > > To: dev at 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 >
