This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wed, Mar 04, 2009 at 05:25:35PM -0500, David VomLehn (dvomlehn) wrote:
it's more a matter of "when" rather than "if". there is still an intention here to use XI (we have SmartMIPS), which requires not using the signal (or FP) trampoline on the stack.
moving the signal trampoline to a vdso (which is(? was?) called, maybe misleadingly, 'vsyscall', on other architectures) is the obvious solution to that part of the puzzle. and yes, it is possible to maintain the ABI; the signal trampoline is still also put on the stack, and modulo XI, would work if used - the trampoline-on-stack is simply not used if there is a vdso with the signal trampoline.
We generally want to get rid of stack trampolines. Trampolines require cacheflushing which especially on SMP systems can be a rather expensive operation.
If I understand this correctly, using a vdso would allow a stack without
execute permission on those processors that differentiate between read
and execute permission. This defeats attaches that use buffer overrun to
write code to be executed onto the stack, a nice thing for more secure
systems.
The good news is that many of these stack buffer overruns don't work on
MIPS anyway due to the somewhat unusual stack frame. Don't rely on that
too much for security though - like 10 years ago Phrack published an
article under the title "Smashing the stack for fun and profit" explaining
how to write exploits for IRIX 5 which als was using o32.
Ralf
Attachment:
PGP.sig
Description: This is a digitally signed message part
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |