[dpdk-dev] Question about ASLR

[Matt Laswell]

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
>