Messages in this thread | | | Subject | Compiler alternatives to no-exec (was Re: non exec stack...) | From | David Wragg <> | Date | 07 Aug 1998 00:49:20 +0000 |
| |
Meelis Roos <mroos@tartu.cyber.ee> writes: > There was a discussion on bugtraq obout bounds checking. That made > programs _very_ slow (AFAIR about 20 times slower sometimes). C is > not designed to be bounds checking - that's why it's so hard.
Yet if people can't learn to avoid the relevant bugs when they program, then it seems to me that ad hoc fixes should be in the language implementation rather than the kernel.
So here's another compiler-based solution: The function entry code saves the return address from the end of the stack frame to the start of the of stack frame. The function exit code compares the saved return address with the possibly overwritten one, and aborts the program if it was changed.
(The abort code could log the end of the smashed stack frame, for later analysis by an exploit-detector proram. Also, with some very small additions to the programs, the identity of the user/client that caused the problem could be logged.)
It would require a couple of extra instructions in the function entry code, and a couple more plus a branch in the function exit code. The compiler could be smart and only insert the extra code for stack frames that contain char arrays.
The slowdown to programs seems likely to be well within the bounds of acceptability, and it would be far easier to implement than general bounds checking.
-- Dave Wragg
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |