Thiemo Seufer wrote:
The trampolines in libffi are user allocated, so there is a choice of
where to place them. In libgcj (which uses the libffi trampolines) the
trampolines are allocated on the heap and care is taken to set the
execute permissions on the memory in question. Other users may have
problems, but by now most code should work as XI support has been
present on x86 for quite some time now.
Brian Foster wrote:
2) Kevin D. Kissell wrote:
2)[ ... ]
2) > Well, strictly speaking, you wouldn't actually *need* to modify
2) > binutils to make specially tagged binaries. [ ... ]
2) This exists already in ld's -z execstack/noexecstack feature.
Good point. Thanks for the reminder.
2) It is not used by default because too many things depend on executable
2) stacks on MIPS.
Ah! Can you be more specific please? At the present time
I'm only aware of three situations where executable stacks
are magically used ("magic" meaning it's being done without
the programmer explicitly coding it):
2. something to do with FPU emulation?
3. pointer to a nested function (gcc extension).
Those, plus manually coded trampolines in e.g. foreign function
interfacing (which are typically hidden in some library). I don't
know if you can ignore that completely. :-)
As long as there is a mechanism to make user space stacks (and heap)
executable, there should be no problem. People running code that
requires it can switch off the XI support.
And, significantly, I am do not know of any need for the
kernel-mode stacks to be executable. Except, perhaps,
for case 3, the above are (should be?) user-land only.
AFAIK nested functions are frowned upon in kernelspace.