Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: Compiler alternatives to no-exec (was Re: non exec stack...) | Date | 7 Aug 1998 06:20:07 GMT |
| |
In article <y7rogtxzkdr.fsf@sytry.doc.ic.ac.uk>, David Wragg <dpw@doc.ic.ac.uk> wrote: >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.
There's an even simpler fix, with the compiler just pushing 0 on entry to all functions, and on exit it pops it off and aborts if it is non-zero.
If somebody is using a overlong string, it cannot contain an all-zero value in the middle, so nobody can use the standard string overflow trick.
Zero also happens to be very cheap to test against. Total overhead: four instructions per function
+ pushl $0 ... + popl %ecx + testl %ecx,%ecx + jne abort ret
However, the proper fix is still to get rid of the buffer overflow. The above has the advantage that you can actually debug it fairly easily.
Linus
- 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
| |