FS#44362 - [pacman] consider adding the -fstack-check switch to CFLAGS
            Attached to Project:
            Arch Linux
            
Opened by Daniel Micay (thestinger) - Thursday, 26 March 2015, 22:29 GMT
Last edited by Allan McRae (Allan) - Thursday, 26 May 2016, 11:37 GMT
          Opened by Daniel Micay (thestinger) - Thursday, 26 March 2015, 22:29 GMT
Last edited by Allan McRae (Allan) - Thursday, 26 May 2016, 11:37 GMT
| 
 | Details
                    The -fstack-stack switch prevents harmful stack overflows by
                    enforcing the guarantee that the guard page at the end of
                    stacks will be hit. It does this by injecting one byte
                    writes for large uninitialized frames and any usage of
                    alloca. It rarely needs to do anything because these cases
                    are rare so it has no performance or code size impact in
                    practice. Without this feature, even "correct" code can cause a stack overflow overshooting the guard page. The most significant change is that an unbounded alloca can only cause a denial of service since it will reliability trigger a segfault. The stack protector feature can only catch buffer overflows past the stack frame boundary, so it provides no protection against these issues. | 
              This task depends upon
              
              
            
            
          
            Closed by  Allan McRae (Allan)
Thursday, 26 May 2016, 11:37 GMT
Reason for closing: Deferred
Additional comments about closing: Currently testing a range of security additions to CFLAGS.
          
        Thursday, 26 May 2016, 11:37 GMT
Reason for closing: Deferred
Additional comments about closing: Currently testing a range of security additions to CFLAGS.
 
                      
the patch fixed the register reservation issue, so there shouldn't by any issues now.
the gcc upstream ticket: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67265
gcc patch: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=230247
I have checked our gcc release and it contains the mentioned patch.
I have also tested to packages. ffmpeg and a problematic (AUR) package lib32-libx264 from the bugreport https://bugs.archlinux.org/task/46019