Re: [Redhat-private-dev] Executable stack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This comes up so often that I think someone (maybe even me?) must have
written a few scripts to help with this, and certainly a FAQ or something.
It's quite easy to track down how this comes about if you have a build of
the thing in question and examine its object files.  By checking the ELF
section headers of each individual object file, you can see which ones have
the executable-stack marker--it only takes one to get the entire DSO or
program binary marked executable.  Roughly, "readelf -S x.o | grep GNU-stack".
X marks the spot. :-) 

Once you've located the object files in question and found their sources,
there are two common cases that are producing this.  One is assembly code
(usually .s or .S files); bare assembly files get no marker, and no marker
defaults to meaning marked executable.  In the assembly code, just add:

	.section .note.GNU-stack
	.previous

That is, unless you think the assembly code might actually use executable
stack.  That you'll have to figure out, but it's an unusual thing for some
assembly code to do.  If it does, make that: .section .note.GNU-stack, "x".

The other common situation is nested functions (a GCC extension in C code).
These can sometimes be made nested inline functions, and optimized away.
Other times it's not hard to just make them static functions.  Sometimes
nested functions are nice to have and it makes the code hairier to avoid
them, so you just want to leave them and acknowledge that executable stack
is going to be required for that program or library.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux