lkml.org 
[lkml]   [1998]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Compiler alternatives to no-exec (was Re: non exec stack...)
Date
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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.146 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site