[Bug other/28328] Stack smash protection non-verbose

[nigelenki at comcast dot net]

------- Comment #12 from nigelenki at comcast dot net  2006-07-11 05:49 -------
(In reply to comment #10)
> (In reply to comment #8)
> 

> That is just a simple (obvious) example, you seem to not understand how real
> code looks like.  You might instead have:
> 
> int f(int a, int b)
> {
>   int f[10];
> .....
>   f[a] = 1;
> ....
>   return f[b];
> }
> 
> Where you know that a should be between 0 and 9 but comming into the function
> it is not, so the value of a is wrong and you have to track down why that is
> which can be a million lines in execution before calling of f.  This is a stack
> smashing bug also, yes a less common one than the obvious ones which you showed
> but it is still going to happen.  The obvious ones are easy to find in an audit
> of the code, unlike this one.  You can add asserts to the function but that
> will produce as much useful info as the info you want from the stack smasher. 
> It is only useful for starting to debug the program, even then you get the
> information just as quick from the debugger.
> 

You make the assumption that I somehow know the bug is in f().  What if I have
a 64 million line program with several hundred thousand functions like this,
and the bug is obscure and hard to reproduce?  Where do I start?  How do I know
the bug is in f()?

(In reply to comment #11)
> (In reply to comment #9)

...

> 
> I am not saying ssp is bad, I am saying it is only a small tool in
> debuging/development and should be kept that way.

Don't worry, it will be.  I am only interested in getting a facility to obtain
information that says to "start somewhere around here."

>  If there are trust problems,
> then ssp is used and the end user is not trusting the developer of the program
> anyways.

SSP is a safety net.  If you can't trust the developer of the program, then you
assume the program is malicious, and don't run it because it's backdoored.  SSP
is not a tool to stop untrusted developers, it's a tool to catch minor
mistakes.

.....

> You forget about
> real end users like say a game player.  He does not care why your program
> crashes, he just wants a fix or he might just ask for a refund since your
> program does not work.
> 

"I am experiencing a crash on level 10, sometimes when I enter this room"

  "OK we'll look into it"  *months go by*

How about:

"I am experiencing a crash on level 10, sometimes when I enter this room"

  "OK, look in ~/level_10_dump.dbg, send me that file" (game supplies an
overriden __stack_chk_fail() that also spits out a debug file) *patch released
4 days later*

I've heard enough stories about being on the phone with Apple for a total of 50
hours or whatnot, it's been fun but I'd rather just e-mail a file or copy-paste
a line of text and be done.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328