Re: 2nd Linux kernel patch to remove stack exec

[linux () MAILHOST UNI-KOBLENZ DE (Systemkennung Linux)]

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