[grsec] Re: [gentoo-hardened] PaX: pageexec or segmexec performance numbers?

[pageexec at freemail.hu]

> Are there any numbers (benchmarks) about the performance penalty of
> pageexec and/or segmexec on intel x86 machines?

i remember only the kernel compiles on P3, for SEGMEXEC the slowdown
was around 1-2%, for PAGEEXEC on 2.2/2.4 it was around 30-40% and
on 2.6 it was 2-3%. i recall spender benchmarking PAGEEXEC on an
athlon and 2.4 and it was something like 20-25%. on P4 PAGEEXEC is
very bad (maybe a 100x slowdown, i don't think anyone bothered to
benchmark it precisely ;-), you don't want to use it.

> The idea that I have is that page-exec on x86 involves a page-fault
> for every (execute) access to a new page that will be treated by
> pax... and that is performance-wise .. bad..

not quite, you get an extra page fault for every data access to
a page that the DTLB doesn't yet have an entry for. the larger
the DTLB the smaller the number of these extra page faults (that's
why the athlon is better than any intel).

> And that segmexec is a diferent approach that involves, mirroring the
> process address space on two segments with diferent "write"
> permissions, and compairing those two, to check if there was any
> overwrite of the code segment.

nope, the difference is not in writability (executable pages are
non-writable, regardless where they are), it's about being present
or not in the 'upper' half of the address space (which happens to
be the code segment), hence being present there equals to being
executable, non-executable otherwise.

> This would mean doubling the mem-usage, at least for the code-segment
> in segmexec mode.

what's doubled is the virtual memory usage (or you can say that the
address space is halved), the underlying physical memory usage doesn't
change (that's the whole point of vma mirroring - it creates two virtual
mappings for the same physical page).

> And in arches that suport no-exec pages (has sparc or amd64), what are
> the performance penalties? Anyone can give me some pointers?

except for ppc there should be nothing measurable there (well, maybe
some contrived benchmark can show something on sparc/sparc64 because
the fast path of the TLB load handler is 2 instructions longer, but
i'd hardly call that 'penalty').

> stuff like: kernel compiles, mysql benches, or... any other benchmark
> is good for me.. just to "grasp" a idea..

maybe http://www.grsecurity.net./grsecurity-slide_files/frame.htm helps
although it's quite old and benchmarks only PAGEEXEC.