Subject: Re: Importing PaX features to NetBSD
To: Elad Efrat <>
From: James Chacon <>
List: tech-security
Date: 12/18/2005 04:29:33
On Sun, Dec 18, 2005 at 12:12:50PM +0200, Elad Efrat wrote:
> Hubert Feyrer wrote:
> >  * under what license is the code to-be-imported (seeing GPL in the ouput
> >    of that test), and
> There is no licensing problem.
> >  * what is the performance impact when this is enabled?
> >    I guess some more benchmarks would be useful to establish that.
> I haven't done any native benchmarks, but I can point you to (some)
> benchmarks already done, available at
>, although I'm not
> sure these are fair wrt/to the features in question.

If they weren't done on NetBSD systems they likely aren't useful. 

> Some information that might help figuring what would be the costs of
> ASLR calculates 3 random values on execution and saves these as offsets
> to be used when a random value is needed. How expensive are 3
> arc4random() calls in the context of an entire sys_execve()?

Who knows overall...Do it and measure it.

> MPROTECT, when not talking about text relocations, is very simple and
> a matter of playing with flags. There's some more work involved when
> handling textrels, but we have both the PaX way and Matt's way to look
> into and decide what would be best for us.

In both cases they need measurements. It's adding overhead so quantifying it
is important. 

> For these two features, the last case of handling textrels *may* present
> the only visible performance hit.
> However, like I already mentioned.. these are security features, and we
> should let the user do the trade-off if desired. We can always have
> these turned off by default.

If they're in the OS as options it's a responsbility of ours to be able
to also tell the user the impact these will have on their performance. This
means doing some measurements and seeing what their impact is.