[dpdk-dev] Question about ASLR

[dpdk-dev] Question about ASLR

[Matt Laswell]

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*

Re: [dpdk-dev] Question about ASLR

[Richardson, Bruce]

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

Re: [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@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
>