This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PT_GNU_STACK


Ulrich Drepper <drepper@redhat.com> writes:

> > It seems to me that it would be better to indicate this using a DT_
> > flag rather than a PT_ segment.
> 
> No.  Just look at how the *kernel* loads an ELF binary.  The kernel
> never looks at the dynamic section.  The only alternative is an ELF flag
> (in e_flags) but that space is too limited and has no OS-specific
> reserved bits.  The program header is exactly the right place for this.

Obviously the kernel could look in the PT_DYNAMIC segment.  But I
suppose that would not be present in a statically linked binary.  So I
guess you are right that a special segment is appropriate.  Ugh.

> > I would suggest a linker option which means ``make the stack
> > non-executable unless some input file requires an executable stack.''
> 
> That's the whole purpose of the patch.  This is the binutils side.  The
> gcc side will hopefully follow.  We need no flag indicating "use
> non-exec when possible" since the presence of the note sections
> indicates just that.  If all input files have the input it is safe to
> add the non-exec flag in the output file.  If the note section is
> missing in one or more input files it is not safe and only the user can
> overwrite the decision by explicitly specifying the appropriate linker
> option.

That condemns us to forever having the note section in all input
files.  I don't think that is good.

I think we need a plan to move to some other approach over time.  That
is what I tried to propose.

It is perhaps worth noting, as I'm sure you know, that many operating
systems always make the stack non-executable.  On those operating
systems gcc generates a function call to make the stack executable
when required.

If gcc generated that function call as a link-once static constructor,
it would be quite efficient.  A version of gcc which generated that
call could always pass -z noexecstack (or whatever) to the linker.
Then we would not have to worry about any input sections.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]