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

James