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

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