lkml.org 
[lkml]   [2005]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
Date
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.
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.063 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site