This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[Fwd: Re: A way to prevent buffer overflow exploits?]


Reading this it sounds like keeping data and return addresses on two
differnt stacks would be a straight-forward thing to implement
in a compiler

 
______________________________________________________________________
 David Nicol 816.235.1187 UMKC Network Operations david@news.umkc.edu
          "The latest monstrous creation from the loathsome..."


On Fri, 31 Jul 1998 05:07:14 +1000, Warner Losh <imp@village.org> wrote:

>In message <98Jul30.074943est.40326@border.alcanet.com.au> Peter Jeremy writes:
>: I wonder how feasible it would be to modify GCC to generate code with two
>: stacks (or something equivalent): one for local variables, the other for
>: parameters and return addresses.

As a point of clarification, that was actually written by "John
D. Hardin" <jhardin@WOLFENET.COM>.

>Foreach function on function entry save the return location and bump a
>pointer.  This is effectively a second stack.  However, no additional
>support is needed from the kernel,

Something needs to manage what happens when this array of saved
return addresses (__global_return_ptr in the sample code) fills
up.  The sample code has no checks for this.

Under a typical Un*x OS, you just keep pushing data onto the stack.
When you reach the end of the allocated stack, the process gets a page
fault (or similar).  The kernel allocates another page of memory for
the stack and the process continues obliviously.  This sort of
functionality needs to be provided for any `second stack' approach -
either within the kernel, or using a SIGSEGV (or similar) handler.

>Having kernel support for two stacks (esp for code, ebp for data)
>would be interesting, but the code generation might be impacted more,
>since ebp is generally referenced with both + and - args for locals
>and parameters respectively.

I don't think so.  From some back-of-envelope scribbles, the changes
are fairly trivial.  The compiler just needs to build a local variable
frame based on the old frame pointer instead of the spack pointer.  If
the parameters are passed on the same stack as local variables, the
function calling code needs to push parameters via the frame pointer
instead of the stack pointer.

Peter
--
Peter Jeremy (VK2PJ)                    peter.jeremy@alcatel.com.au
Alcatel Australia Limited
41 Mandible St                          Phone: +61 2 9690 5019
ALEXANDRIA  NSW  2015                   Fax:   +61 2 9690 5247



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]