grsecurity forums

Hi all,

I saw that AMD implemented a NX bit inside its AMD64 processors as Athlon64 and Opteron.
At first glance, it sounds good for segregation.

My question is: are the architecture based on such processor finally more robust ?
Is the NX bit really used by kernels and applications ?

Thanks

evilangel wrote:My question is: are the architecture based on such processor finally more robust ?
Is the NX bit really used by kernels and applications ?

not sure what you mean by more robust, but the NX bit has been in use ever since it got introduced in amd64 (and later, intel's em64t).

not sure what you mean by more robust

1/ I thought of the quality of the implementation of NX.
It could be written nicely on the paper, but how is it in real life?
Are OS/binaries really using it, or bypassing this feature to ease their developpement (as often with security feature).

2/ In the case NX implentation is good, does it mean that PaX becomes useless when running an AMD64 proc ?

Thanks

It it my understanding (correct me if I'm wrong) that 1) the hardware implementation has a performance impact so minute you will never notice and 2) with a system that does not have NX bit set, PaX needs to emulate this, which _is_ a noticeable performance impact. That is, if you do have the NX bit, your performance incrase is due to PaX not having to emulate it.

evilangel wrote:1/ I thought of the quality of the implementation of NX.
It could be written nicely on the paper, but how is it in real life?
Are OS/binaries really using it, or bypassing this feature to ease their developpement (as often with security feature).

it's a good question and the answer depends on whose kernel and userland you're using as well (you can search this forum for related troubles under debian/etc). the basic problem with any new feature that restricts something previously not controllable is that of backward compatibility and policy for future apps. the vanilla kernel's approach to both leaves a lot to be desired (GNU_STACK handling, READ_IMPLIES_EXEC personality, noexec kernel command line, etc). until very recently, it was trivial to get around any of the kernel's userland NX handling, lately SELinux can enforce what is called MPROTECT in PaX, but then who wants to use SELinux for just that...

2/ In the case NX implentation is good, does it mean that PaX becomes useless when running an AMD64 proc ?

PaX is more than merely implementing a NX bit, you should read pax.txt and noexec.txt on the docs page i think . on archs that have proper hw NX support there's still a lot to do to control runtime code generation (especially on archs whose userland ABI is badly designed and requires it for all binaries). then there's the kernel's use of non-executable pages for its own memory, again, until very recently it was pretty bad, some of the recent x86 unification work made it better, but it's still far from good enough.