My libdyninstAPI_RT.so is also marked as needing an executable stack. I
don't think there's an intentional reason for this--it's probably a bug.
From some quick googling, a library will be marked as needing an
executable stack if any of its object files don't have the
.note.GNU-stack section. The libdyninstAPI_RT.so library has numerous .o
files that are built from assembler and wouldn't include this section.
I just tried appending the line:
.section .note.GNU-stack,"",@progbits
to the bottom of every file in dyninst/dyninstAPI_RT/src/*.[Ss]. After a
rebuild the resulting libdyninstAPI_RT.so was no longer marked as needing
an executable stack.
Could you give this a try and let us know whether it fixes the problem?
-Matt
On Mon, 29 Dec 2014, Sergej Proskurin wrote:
Hello,
I have noticed that after a binary has been statically rewritten with
help of Dyninst, its stack is marked as executable. Even after
modification of the PT_GNU_STACK program header (RW), the stack remains
executable -- (this may be observed e.g. by means of 'pmap' on Linux).
The mentioned process of binary rewriting does not make much: in my case
Dyninst creates a wrapper for the _init() function and includes another
segment (marked as RWE) comprising among others a new .dynamic section
and a section containing the wrapper code. But even, if the program does
not create a wrapper code (so no additional .text section in the
dynsinst specific segment is needed), the stack of the resulting binary
remains executable.
/* snippet of the readelf output */
Program Headers:
...
LOAD 0x005000 0x08100000 0x08100000 0x0049f 0x0049f RWE 0x1000
...
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10
...
(as already mentioned above: the deletion of the E flag of the GNU_STACK
program header does not help)
Section to Segment mapping (Segment 04 is the LOAD segment from above):
...
04 .dyninstInst .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r
.rel.dyn .rel.plt .dynamic
...
/* snippet end */
First I thought of manually moving all relevant parts of the .dynamic
section, created by Dyninst to another segment and mark it as RW. Thus,
the other parts of the .dynamic Segment could be marked as RW and and
the remaining parts of the LOAD segment created by Dyninst as RE. I
thouth there might be a connection between this LOAD segment and the
need for an executable stack... However, this does not seem to be a
solution here, since I have marked the complete section as RW (just for
testing) and the stack was marked as RWE, as well.
Dyninst inserts an additional library dependency to the binary, namely
"libdyninstAPI_RT.so.8.2". This library seems to has (in my case) a
PT_GNU_STACK program heder, which specifies an executable stack (RWX).
If I have understood it correctly, the dynamic linker (loader) will mark
a binary's stack as executable if a library dependency requires an
executable stack. But I am not sure in what way this information should
help me in this case: The delection of the library dependency
"libdyninstAPI_RT.so.8.2" would certainly lead to a non-working binary...
I was wondering whether you could provide me information about what
needed to be done so that the stack of rewritten binaries is marked by
the loader according to the PT_GNU_STACK program header permissions?
Thank you very much in advance.
Best regards,
Sergej
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}