Messages in this thread | | | Subject | Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer) | From | Arjan van de Ven <> | Date | Wed, 02 Feb 2005 10:52:38 +0100 |
| |
On Wed, 2005-02-02 at 10:35 +0100, Peter Busser wrote: > Hi! > > > Umm, so exactly how many applications use multithreading (or otherwise > > trigger the GLIBC mprotect call), and how many applications use nested > > functions (which is not ANSI C compliant, and as a result, very rare)? > > > > Do the tests both ways, and document when the dummy() re-entrant > > function might actually be hit in real life, and then maybe people > > won't feel that you are deliberately and unfairly overstating things > > to try to root for one security approach versus another. > > Well, you can already do the test both ways. There is a kiddie mode, which > doesn't do this test. And a blackhat mode, which does it. Basically removing > the mprotect and nested function is demoting blackhat mode into kiddie mode.
actually you don't. The presence of the nested function (technically, the taking of the address of a nested function) marks the PT_GNU_STACK field in the binary, not the runtime behavior. As such, paxtest does not offer any real such choice in behavior. The binary needs stack trampolines, just that in one case you don't use them.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |