Martin McClure wrote:
> Gerardo Richarte wrote:
>> 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.
> 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.
I'm not sure, mprotect() is supposed to work on any memory allocated
to the process, regardless of the allocation method. In fact, the man
page for mprotect() in my linux (ubuntu) has a code example allocating
memory with memalign(), and the using mprotect() on it. I didn't know
what memalign() is, but its man page says it calls malloc(). So I guess
it should be fine and legal to do malloc()+mprotect().
On other systems, mprotect() is supposed to work on any memory
location (.text, .bss, .data, stack, etc) as long as it's mapped in the
process, and sometimes even further. Using an unaligned address is
probably not completely legal, so you may want to use
sysconf(_SC_PAGE_SIZE) to get the page size (in Linux).
> 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.
true, but it's also not so standard, specially across different
unixes (or maybe linuxes)
If you are interested, I have some linux flavors and other linuxes
and windows versisons where I could do some tests.
richie
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
