Re: Non-Exec stack patches

From: David Mosberger
Date: Wed Mar 24 2004 - 02:47:46 EST

>>>>> On Wed, 24 Mar 2004 02:28:40 -0500, Jakub Jelinek <jakub@xxxxxxxxxx> said:

Jakub> On Tue, Mar 23, 2004 at 11:16:36PM -0800, David Mosberger
Jakub> wrote:

>> I'm not following you on the "get handling free" part. How
>> is that handling free?

Jakub> What I meant is that it is already written and tested.

OK. The ELF flags bit is even more free, then... ;-)

>> Actually, that's something that worries me. Somebody just needs
>> to succeed in loading any shared object with the right
>> PT_GNU_STACK header and then the entire program will be exposed
>> to the risk of a writable stack. On ia64, I just don't see any
>> need to ever implicitly turn on execute-permission on the stack,
>> so why allow this extra backdoor?

Jakub> What kind of backdoor is it? If you dlopen untrusted shared
Jakub> libraries into your program you have far bigger problem than
Jakub> executable stack (you can execute any code it wants in its
Jakub> constructors).

Sure. Theoretically, none of this matters at all (thanks to
mprotect()), so we're justs talking about raising the barrier. With
PT_GNU_STACK, it's sufficient to tweak one bit in any dependent
library, whereas with the ELF flag bit, you need to tweak one bit in
the main executable. Not a huge difference, I'll submit, but from an
admin perspective, I find it a lot easier to check the main program to
see if it has the "executable stack/data" bit set rather than all
dependent libraries. Additionally, we could easily choose to drop
support for the ELF flag bit altogether. The only program that I know
of that ever needed executable data was XFree86 and that was only due
to an oversight---and that has long been fixed.

Jakub> If there is a shared library which needs executable stack for
Jakub> its use (on !IA64 !PPC64 this is e.g. any library which takes
Jakub> address of a nested function and passes it to some other
Jakub> function and/or stores it into some variable which cannot be
Jakub> optimized out, on IA64 or PPC64 this is of course much rarer,

For sufficiently small values of "much rarer", I agree. ;-)

Jakub> but it is still possible some language interpreter or
Jakub> something builds code on the fly on the stack).

That's why there is mprotect().

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at