Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)

[Arjan van de Ven <arjan@infradead.org>]

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.