Re: [gentoo-hardened] simple PaX memory protection benchmark

On 8 Aug 2005 at 17:23, Pedro Venda wrote:
> I've written a small document describing a simple benchmark of the PaX memory
> protections overhead on different x86 CPUs. There is a theoretical section
> where I try to explain what do PAGEEXEC and SEGMEXEC actually do, there is
> the benchmark itself and some notes on the results.
>
> http://arrakis.dhis.org/linux/doc/pax-performance/
>
> Hoping to get back some comments but mostly wrong or misleading data reports.

first of all, a big thank you for doing this work, it was badly
missing from the PaX docs. below i'll comment on a few things:

1. PaX stands for the [Pa]ge E[X]ecute right or PAGE_EXEC, which is
   the symbolic name commonly used on operating systems that offer
   memory protection. of course this is historical now, PaX does more
   than merely create (non)executable memory pages, but that's how it
   started 5 years ago.

2. you talk about preventing 'arbitrary privileges', but it's more
   about preventing exploitation of memory corruption bugs. the
   'arbitrary' part comes from the assumed ability attained by the
   attacker: arbitrary read/write access to the attacked process's
   memory.

3. for the randomization features, PaX has also randomized the brk()
   based heap for like 2 years now, it's just that i didn't get around
   to document it yet.

4. some newer IA-32 CPUs do have NX support, but i haven't prepared
   PaX to use it yet (on amd64 in 64 bit mode it works of course).

5. it's not the writable but the present (readable) bit that makes
   a page executable on IA-32.

6. in general, instead of trying to reword the PaX docs, it's better
   to include the original, you'll avoid the interpretation mistakes
   that i'm in no mood to list here (it's being 2 AM and a performance
   test probably just doesn't need all this extra info anyway...).

7. the PAGEEXEC/i386 performance impact is lower than what it used
   to be because a year ago i implemented a speed-up trick on 2.6
   (it's not documented yet). you can try to test 2.4 and you'll see
   what i mean, especially on the P4 where the old PAGEEXEC logic
   would cause a huge slowdown, maybe a 100x or on that order (so
   what you observed shows just how effective the speed-up is in
   real life). i don't know why the P4 is so impacted, it's probably
   in part because user/kernel transitions are very slow in general,
   but there must be something else as well (the PaX specific page
   table manipulation maybe).

8. it's interesting that you also found the same small performance
   increase for SEGMEXEC/P3 that i'd observed in the past, it's really
   small but consistent: userland time goes down (unexpected), kernel
   goes up a bit (expected), on the order of a few seconds on a kernel
   compilation. i have no explanation for this, but it's quite
   reproducible (i used to think that randomization causes it but then
   it affects only virtual addresses, not the physical addresses which
   play a role in caching, and you didn't have randomization enabled
   at all, i think).

9. SEGMEXEC/amd64 doesn't exist because the CPU itself doesn't make
   it possible (nor necessary, of course), at least in 64 bit mode.
   in 32 bit mode you can of course boot the normal i386 kernels and
   test both non-exec methods.

so, that's all for now, let me know when you're finished with the
page and i'll link it from the PaX doc page.

-- 
gentoo-hardened@g.o mailing list