> -----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
