Re: Stack Overflow Detection

Tomás Ó hÉilidhe wrote:
On May 30, 3:51 pm, "Richard Phillips" <raphill...@xxxxxxxxxxxx>
wrote:
Hello all,

I'm thinking about implementing the above in a system I'm working
on, does anyone have a good strategy for doing this?
One possibility is having an area of RAM (beyond the stack "area")
filled with known data, if any of that data gets trashed then assume
the stack has overflowed. What are the pros and cons of this?
Another idea is to actually watch the SP, but one drawback is if I
check this at a predefined point in the code, then it's possible the
worst case scenario will occur between checks?
Any better ideas?


Obviously if the stack overflows then that's a sign of flaw in the
programming, so really you're trying to implement a system that
accommodates buggy programming and just peforms a "salvage operation"
by killing the program before it can do any damage... do I understand
correctly?

To my knowledge there are two symptoms of stack overflow:
1) The stack pointer being greater than it should be
2) Data after the stack pointer getting changed

As you've said, you can't really rely on the first one because it
could go forward and then move back to a safe area. As for the second,
well it has a very good chance of working, but there's still a 1 in
256 chance that the corrupt byte will be exactly equal to the "test
value" :-P

Assuming that I'm right in saying that you'll just kill the program if
the stack overflows, what will be the benefit of this? Will it stop
the Green Laser of Death from being turned on, or will it stop
permanent storage from being corrupted or something like that?

The stack isn't currently overflowing, in so far as the software isn't going
nuts for no obvious reason, I guess I'm looking at having something that can
detect a situation where the heap data might "collide" with the stack data.
I suppose one problem is I've not previously defined what I mean by
"overflowing", I think the previous line corrects this.
As for the action to take if a problem is detected, I suppose a reset would
be a good start. But then I suppose if there is a situation where such a
problem occurs, it's probably going to reoccur.
I don't expect this to ever be a problem, but on a previous project there
was a requirement to have this safety feature. It's not required on this
project, but I was thinking about adding it anyway.

Thanks,
Richard.


.

Relevant Pages

  • Re: Stack Overflow Detection
    ... One possibility is having an area of RAM (beyond the stack "area") filled ... Obviously if the stack overflows then that's a sign of flaw in the ... Or in some systems, HW failures, EMI or radiation events. ... accommodates buggy programming and just peforms a "salvage operation" ...
    (comp.arch.embedded)
  • Re: Stack Overflow Detection
    ... if any of that data gets trashed then assume the stack has overflowed. ... Obviously if the stack overflows then that's a sign of flaw in the ... accommodates buggy programming ... Another safety feature could be to have a stack checker kicking in once in a while, which goes into an error handler if it detects an overflow, gracefully shutting down any dangerous equipment (which could be a fresh process that starts after the scheduler has suspended all other processes). ...
    (comp.arch.embedded)
  • Re: glibc glob_filename() recurse call stack overflow (Re[2]: Bash Blues)
    ... I don't think this is a glibc issue. ... have a bigger stack, or better exception handling. ... Anyway, on the subject of exploiting stack overflows, I'm really only ... memory, and create fake heap control blocks, as you would in a heap ...
    (Vuln-Dev)
  • Re: Stack Overflow Detection
    ... One possibility is having an area of RAM (beyond the stack "area") filled ... Obviously if the stack overflows then that's a sign of flaw in the ... accommodates buggy programming and just peforms a "salvage operation" ... 256 chance that the corrupt byte will be exactly equal to the "test ...
    (comp.arch.embedded)
  • Re: Recursive structures
    ... Leif K-Brooks: ... from time import clock ... to be iterative (using a list as a stack) to avoid such stack overflows ...
    (comp.lang.python)