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

[Peter Busser <busser@m-privacy.de>]

On Wednesday 02 February 2005 09:26, Theodore Ts'o wrote:
> On Tue, Feb 01, 2005 at 07:15:49PM -0500, Theodore Ts'o wrote:
> > Umm, so exactly how many applications use multithreading (or otherwise
> > trigger the GLIBC mprotect call),
>
> For the record, I've been informed that the glibc mprotect() call
> doesn't happen in any modern glibc's; there may have been one buggy
> glibc that was released very briefly before it was fixed in the next
> release.  But if that's what the paxtest developers are hanging their
> hat on, it seems awfully lame to me.....
>
> "desabotaged" seems like the correct description from my vantage
> point.

Well, great! One problem eliminated.

Anyways, for me it is not important whether what GLIBC exactly does or doesn't 
do. There are tons of different libraries and applications which do all kinds 
of stuff. You can only guess what exactly goes on. And not all compilers 
generate PT_GNU_STACK stuff either. And so on and so forth.

What is important to me is the question whether the PaXtest results are 
accurately reflecting the underlying system or not. Therefore I would like to 
see proof that exec-shield does NOT open up in situations where PaXtest says 
it does. So far I have seen ``sabotage'' FUD, opinions and excuses. But no 
proof. Nor any reasonable evidence. That doesn't surprise me, because PaXtest 
is accurate in what it does.

Groetjes,
Peter.