Messages in this thread | | | From | Systemkennung Linux <> | Subject | Re: 2nd Linux kernel patch to remove stack exec | Date | Mon, 14 Apr 1997 01:34:30 +0200 (MET DST) |
| |
Hi,
> Firstly I want to say that if I remember Linus's opinion on this > matter from some time ago this sort of change is not going into the > kernel, in fact you essentially have to allow any data segment to be > executable. If you break this all sorts of "fun" things happen, > crashme stops working (bad bad bad), certain high performance > scheme/lisp interpreters stop working, and you break our current > signal returning mechanism which is used on all platforms.
Unfortunately Linus is right in his opinion that a lot of software will break.
The attempt these problems by removing execute permission is also limited by the problem that some architures like MIPS don't make a difference at all between read and execute permissions for a page, on others like 68k the price on would have to pay for these (additional level in page tables plus much memory for the page tables) is way to high.
> > AFAIK, they will cause some overhead for maintaining L1 code and data caches > > coherency, since the stack frame is usually in the data cache -- resulting in > > bad performance. > > We're talking about some hundred cycles or more ... > > Care to propose another way to handle signal dispatch in a clone() > safe way? We used to do signals stupidly via a libc static signal > dispatch vector on the Sparc (this is the way SunOS did it), then I > considered the clone() threaded signal problem, man did I change over > to the way the Intel and Alpha always did it but fast, I'll eat the > instruction cache flush any day compared to the alternative.
Actually I was only arguing against the use of the trampolines generated for certain constructs by GCC. When flushing the caches for the signal trampoline is lower in comparison because we don't take the syscall overhead but hmmm... You asked for it ... (ringing up the department for dirty tricks ...)
When setting up the exception frame put an invalid address that on return from the signal handler will cause some exception. On MIPS I'd choose address error. Check in the exception handler for that particular magic return address from the stack frame -> no more code on the stack and thread safe.
Ralf
| |