[Bug c/38274] New: why the option "-fstack-protector-all" doesn't works?

[Bug c/38274] New: why the option "-fstack-protector-all" doesn't works?

[zuogang at huawei dot com]

source file:
#include <stdio.h>

int main(void)
{
        char a = 1;
        int b = 2;
        short c = 3;
        char sztmp[22] = "hello worlds!";

        *(int *)&a=0xffff;

        sztmp[22]=0;
        printf("%s,a:%d,b%d\n",sztmp,a,b);

        return 0;
}

invoke gcc by :gcc  -fstack-protector-all test.c;

after my debugging a.out, I find the gcc doesn't adding a guard variable to
functions's local stack vars, and the var "sztmp" follows var "a" and there
aren't any room between the two vars.


-- 
           Summary: why the option "-fstack-protector-all" doesn't works?
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: zuogang at huawei dot com
  GCC host triplet: x86, SUSE 10 ES,
GCC target triplet: X86


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

[Bug middle-end/38274] why the option "-fstack-protector-all" doesn't works?

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-11-29 03:10 -------
Works for me with the trunk on i386-darwin8.11:
[236:~] apinski% ~/local-gcc/bin/gcc t.c  -fstack-protector-all 
[236:~] apinski% ./a.out
?,a:-1,b2
*** stack smashing detected ***:  terminated
Illegal instruction


-- 


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

[Bug middle-end/38274] why the option "-fstack-protector-all" doesn't works?

[zuogang at huawei dot com]

------- Comment #2 from zuogang at huawei dot com  2008-12-01 10:13 -------
(In reply to comment #1)
> Works for me with the trunk on i386-darwin8.11:
> [236:~] apinski% ~/local-gcc/bin/gcc t.c  -fstack-protector-all 
> [236:~] apinski% ./a.out
> ?,a:-1,b2
> *** stack smashing detected ***:  terminated
> Illegal instruction

what 's the version of the gcc src code you tried? 

can you try the gcc version 4.1.2


-- 


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

[Bug middle-end/38274] why the option "-fstack-protector-all" doesn't works?

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2008-12-24 01:47 -------
(In reply to comment #2) 
> what 's the version of the gcc src code you tried? 

Trunk meaning 4.4.0.


-- 


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

[Bug middle-end/38274] why the option "-fstack-protector-all" doesn't works?

[howarth at nitro dot med dot uc dot edu]

------- Comment #4 from howarth at nitro dot med dot uc dot edu  2008-12-24 02:53 -------
Zougang,
    Considering they just closed the gcc 4.2 branch, the earliest one worth
testing would be gcc 4.3.2.


-- 


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

[Bug middle-end/38274] why the option "-fstack-protector-all" doesn't works?

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38274

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
-fstack-protector (-all) does not detect all buffer overflows and is not
designed that way (or even documented that way). It only adds one space at the
end of the stack to detect if there was a buffer overflow but it is also
aligned so it might be further out than just one location too.

[Bug middle-end/38274] why the option "-fstack-protector-all" doesn't works?

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38274

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note if you want to detect more buffer overruns you should try
-fsanitize=address
 . Valgrind will also detect more too.
BUT note none of these are 100% either because they only have a limited redzone
and valgrind also will detect less due to if two buffers are on the stack there
is no zone inbetween the buffers.