Subject: Re: Importing PaX features to NetBSD
To: Elad Efrat <elad@NetBSD.org>
From: James Chacon <jmc@NetBSD.org>
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
> http://www.pjvenda.org/linux/doc/pax-performance/, 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 and MPROTECT:
> 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
> 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.