Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: 2nd Linux kernel patch to remove stack exec
From: linux () MAILHOST UNI-KOBLENZ DE (Systemkennung Linux)
Date: Mon, 14 Apr 1997 01:34:30 +0200


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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault