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

[Pedro Venda]

Attempt one:

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

I'm ashamed. I could swear that Prevent Arbitrary eXecution was the 
"translation" found on the official documents, but after your comment I 
looked for it and didn't find it anywhere... It is obviously wrong and I need 
to fix it ASAP. Sorry for the mistake.

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

Agree. On the other hand, the exploits aim at doing something otherwise 
denied, hence the privileges reference. To be fixed also.

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

since I focus ASLR very lightly (only to say it's there), I'll add a reference 
to that but no more. To be fixed.

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

Never heard of them. Are those the newer Xeon with 64bit extensions?

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

Yes, I've researched a bit and didn't get it clear. The bit we're talking here 
is the user/supervisor bit and it's the only one there, right? After the page 
walk, if the bit is set for user, it get's cached in the TLB and becomes 
readable/executable, right? To be fixed after clearing up.

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

Please notice that I'm not rewording the official docs to make the text seem 
my own! If you'd like I'll add local references for specific docs. 
For the article's purpose, I wanted to give a small theoretical insight to 
justify the results. I'll review it and say something later.

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

I've read some postings about this in this list. Unfortunately, of the 3 
testbenches I can only freely access one of them (it's mine actually). The 
pentium 4 and the dual opteron are computers I had access at work but:
1. I don't work there no more.
2. Both are in production now.
So I cannot repeat the tests with kernel 2.4. It'd be interesting though.
Maybe later I'll have access to a p4 again and redo that little test just for 
the kicks, with some info about your trick.

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

Strange that's actually a reproducible performance increase. I'll add a note 
on that.
I found it weird also, and interpreted it as statistical error. I'll give it a 
try on my centrino laptop and see if it's reproducible here.

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

thanks for the explanation on that. I haven't investigated on amd64 and just 
gave a small explanation about why thinking about segmexec would be a waste 
of time really. To be fixed.

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

If you find it good enough, please do, thanks.

regards,
pedro venda.
-- 

Pedro João Lopes Venda
email: pjvenda < at > arrakis.dhis.org
http://arrakis.dhis.org