David Daney wrote:
> Thiemo Seufer wrote:
> > Brian Foster wrote:
> >> 2) Kevin D. Kissell wrote:
> >> 2)[... ‘ld -z noexecstack’ ] is not used by default because too many
> >> 2) things depend on executable 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):
> >>
> >> 1. sigreturn.
> >> 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. :-)
>
> 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.
David, thanks for clarifying Thiemo's point; I wasn't
quite sure what he meant by “foreign functions” albeit
(as it happens) apparently guessed correctly. And for
the specific example of ‘libffi’ (and ‘libgcj’); that's
a new library (to me).
> 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.
Agreed. It is (alas?) important for the general case and
the longer term. But it's plausible that for the specific
case I have, it's not important and maybe not even wanted.
(I'm working in a security paranoid/sensitive area .... .)
Please note this is rather *speculative* ATM!
It's case 2 (above), the trampoline that has “something
to do with FPU emulation”, which has me concerned ATM.
The 4KSd core does not have an FPU. That encourages the
use of ‘-msoft-float’ (at least for performance), but does
not require it. (Albeit I wonder if, in the restricted
world I'm playing in, if it could be “required” (assuming
it doesn't have an issue?)? Hum .... .)
The quick summary (which I'm sure others on this list can
clarify/correct) is the FP trampoline, which is pushed on
the user-land stack is, unlike sigreturn, not fixed code.
It varies on a per-instance per-thread basis. Hence the
simple ‘vsyscall’ mechanism ((to be?) used for sigreturn)
is inappropriate.
The trampoline is only used to execute a non-FP instruction
(<instr>) in the delay slot of an FP-instruction:
<instr> # Non-FP instruction to execute in user-land
BADINST # Bad instruction forcing return to FP emulator
COOKIE # Bad instruction (not executed) for verification
<epc> # Where to resume execution after <instr>
Belch! ;-\ Whilst I can think of a few things that may work
(temporarily change page permissions; or go ahead and use
the ‘vsyscall’ page with some interlocking magic; or a new
new dedicated per-thread page; or ...?) none seem appealing.
Suggestions? Comments? Prior art to study?
thanks & cheers!
-blf-
( I'm experimenting with a new technique for posting to the
list to save me some hassle. It *should* work, but .... ! )
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
