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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
