Gerardo Richarte wrote:
Martin McClure wrote:
There doesn't seem to be a way to malloc memory that's executable in
this kind of system, so I fixed it by using mmap/munmap instead of
malloc/free.
As far as I know there is no way, unless you either globally turn
non-executable heap off, or, on some systems, turn it off per process
(it depends on the operating system, on windows, for example, it's a
"legal" library call, on other unixes there are tricks).
However, on most unixes (unless they use PaX, for example), you can
first malloc() and then mprotect() the returned address so it is rwx, on
some others you can't have W+X, so you have to first make it
write+non-exec, and then, non-write+exec.
I'll see if I can find the call that will disable it in linux (for
example, mprotect(0,...,0xffffffff,READ | WRITE | EXEC) should turn all
memory rwx (constants and arguments are probably wrong, just use them as
guide). However, it does depend on the kernel you are using.
On some systems (PaX) W+X it's absolutely forbiden unless you disable
that feature for the executable ELF (using chpax)
Thanks. It looks like this would work on Linux, but according to the man
page the combo of malloc() and mprotect() isn't POSIX-legal. Maybe in
practice there's no problem, I don't know.
Ian pointed me to the execstack utility and linker flag, which set a
flag in the ELF binary saying that the binary expects to execute from
its stack pages. On Linux, this seems to also also set X permission on
malloced memory, and so solves the problem.
Regards,
-Martin
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
