search for: __stack_chk_guard

I am trying to implement stack probes for our SHAVE target, and I see that the compiler injects references to '__stack_chk_guard' and '__stack_chk_fail'. The code that gets generated is horribly wrong, but in order to understand how to fix it I was wondering if there is a clear statement of how the mechanism is supposed to work? The variable '__stack_chk_guard' appears to be a pointer to an unsigned...

On Thu, Jun 30, 2016 at 8:29 AM, Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I am trying to implement stack probes for our SHAVE target, and I see that > the compiler injects references to ‘__stack_chk_guard’ and > ‘__stack_chk_fail’. The code that gets generated is horribly wrong, but in > order to understand how to fix it I was wondering if there is a clear > statement of how the mechanism is supposed to work? > __stack_chk_guard is loaded and the resulting value is stored on the stack....

When -fstack-protector is turned on, linker fails to find the symbol "__stack_chk_guard" because at least for powerpc64le, glibc doesn't provide this symbol. Instead, they put the stack guard into TCB. x86 fixed this issue by injecting a special address space (which is later translated to TCB register access) and hard code the offset of stack_guard, but I don't see a eas...

...erd.com> > Date: Sat Mar 9 08:55:37 2013 +1100 > > configure.ac : Don't enable stack protector for mingw* host_os. > Hi, Please do a link time test instead, I am not getting this error and would like to keep stack protector on. The test case below will trigger ___stack_chk_guard to emit. int main(){ int i = 0; char a[1000]; while(1){ a[i] = 0; i++; } } "i686-w64-mingw32-gcc -D_FORTIFY_SOURCE=2 -fstack-protector --param ssp-buffer-size=4 -v" shows that libssp is already added. -------------- next part -------------- A non-text attachment was sc...

...e been introduced on 5 Mar 2013 >> with commit 05609d5 (configure.ac : Add hardening compile options.) > Resending, likely caught by filters. Hi, Please do a link time test instead, I am not getting this error and would like to keep stack protector on. The test case below will trigger ___stack_chk_guard to emit. int main(){ int i = 0; char a[1000]; while(1){ a[i] = 0; i++; } } "i686-w64-mingw32-gcc -D_FORTIFY_SOURCE=2 -fstack-protector --param ssp-buffer-size=4 -v" shows that libssp is already added. Alternatively, to include __stack_chk_fail, use: extern void __stack...

...16 6:59:50 PM > Subject: Re: [llvm-dev] [PPC] Linker fails on -fstack-protector > On Mon, Jan 25, 2016 at 11:58 AM Tim Shen via llvm-dev < > llvm-dev at lists.llvm.org > wrote: > > When -fstack-protector is turned on, linker fails to find the > > symbol > > " __stack_chk_guard" because at least for powerpc64le, glibc > > doesn't > > provide this symbol. Instead, they put the stack guard into TCB. > > > x86 fixed this issue by injecting a special address space (which is > > later translated to TCB register access) and hard code the of...

...] [PPC] Linker fails on -fstack-protector >> >> >> >> >> >> On Mon, Jan 25, 2016 at 11:58 AM Tim Shen via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> When -fstack-protector is turned on, linker fails to find the symbol "__stack_chk_guard" >>> because at least for powerpc64le, glibc doesn't provide this symbol. >>> Instead, they put the stack guard into TCB. >>> >>> x86 fixed this issue by injecting a special address space (which is >>> later translated to TCB register access) an...

...untu1). I think that the problem might have been introduced on 5 Mar 2013 with commit 05609d5 (configure.ac : Add hardening compile options.) Gives errors like this:- /home/user/FLAC_build/flac-05609d5/src/libFLAC/.libs/libFLAC.a(ogg_helper.o):ogg_helper.c:(.text+0x173): undefined reference to `___stack_chk_guard' /home/user/FLAC_build/flac-05609d5/src/libFLAC/.libs/libFLAC.a(ogg_helper.o):ogg_helper.c:(.text+0x45c): undefined reference to `___stack_chk_guard' /home/user/FLAC_build/flac-05609d5/src/libFLAC/.libs/libFLAC.a(ogg_helper.o):ogg_helper.c:(.text+0x463): undefined reference to `___stack_chk...

...real problem was a compilation failure when "--enable-hardening" is used. Demonstration: # echo 'int main(){char a[1]; strcpy(a,a);} ' | gcc -w -fstack-protector-strong -x c - Undefined first referenced symbol in file __stack_chk_guard /var/tmp//cc12L9zV.o (symbol scope specifies local binding) ld: fatal: symbol referencing errors. No output written to a.out collect2: error: ld returned 1 exit status I'm not sure if this is a Solaris10 fumble, but configuring "--disable-hardening" removes...

...gt; >>>> >>>> >>>> >>>> On Mon, Jan 25, 2016 at 11:58 AM Tim Shen via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>>> When -fstack-protector is turned on, linker fails to find the symbol "__stack_chk_guard" >>>>> because at least for powerpc64le, glibc doesn't provide this symbol. >>>>> Instead, they put the stack guard into TCB. >>>>> >>>>> x86 fixed this issue by injecting a special address space (which is >>>>> lat...

...order .set nomacro .set noat # BB#0: lui $2, %hi(_gp_disp) addiu $2, $2, %lo(_gp_disp) addiu $sp, $sp, -64 $tmp2: .cfi_def_cfa_offset 64 sw $ra, 60($sp) # 4-byte Folded Spill $tmp3: .cfi_offset 31, -4 addu $gp, $2, $25 sw $7, 76($sp) sw $6, 72($sp) sw $5, 68($sp) lw $3, %got(__stack_chk_guard)($gp) lw $1, 0($3) sw $1, 56($sp) sw $4, 52($sp) sw $zero, 48($sp) // i sw $zero, 44($sp) // val sw $zero, 40($sp) // sum addiu $1, $sp, 68 sw $1, 16($sp) // arg_ptr1 sw $zero, 48($sp) b $BB0_2 addiu $2, $zero, 40 $BB0_1: # in Loop: Header=BB0_2 Depth=...

...i(_gp_disp) > addiu $2, $2, %lo(_gp_disp) > addiu $sp, $sp, -64 > $tmp2: > .cfi_def_cfa_offset 64 > sw $ra, 60($sp) # 4-byte Folded Spill > $tmp3: > .cfi_offset 31, -4 > addu $gp, $2, $25 > sw $7, 76($sp) > sw $6, 72($sp) > sw $5, 68($sp) > lw $3, %got(__stack_chk_guard)($gp) > lw $1, 0($3) > sw $1, 56($sp) > sw $4, 52($sp) > sw $zero, 48($sp) // i > sw $zero, 44($sp) // val > sw $zero, 40($sp) // sum > addiu $1, $sp, 68 > sw $1, 16($sp) // arg_ptr1 > sw $zero, 48($sp) > b $BB0_2 > addiu $2, $zero, 40 > $BB0_1:...

...> ????"--enable-hardening" is used.? Demonstration: > > ????# echo 'int main(){char a[1]; strcpy(a,a);} ' | gcc -w > -fstack-protector-strong -x c - > ????Undefined?????????????????????? first referenced > ???? symbol???????????????????????????? in file > ????__stack_chk_guard?????????????????? /var/tmp//cc12L9zV.o? (symbol > scope specifies local binding) > ????ld: fatal: symbol referencing errors. No output written to a.out > ????collect2: error: ld returned 1 exit status > > ????I'm not sure if this is a Solaris10 fumble, but configuring > ????&q...

...e info available. #24 0x00007fffffffe308 in ?? () No symbol table info available. #25 0x00000001005333d0 in ?? () No symbol table info available. #26 0x0000000000000001 in ?? () No symbol table info available. #27 0x00007fffffffe308 in ?? () No symbol table info available. #28 0x0000000800ace8b0 in __stack_chk_guard () from /lib/libc.so.7 No symbol table info available. #29 0x0000000000000001 in ?? () No symbol table info available. #30 0x00007fffffffe2e0 in ?? () No symbol table info available. #31 0x00007fffffffe318 in ?? () No symbol table info available. #32 0x00007fffffffe308 in ?? () No symbol table info...

Which part of the generated code do you think is not correct? Could you be more specific? I compiled this program with clang and ran it on a mips board. It returns the expected result (21). On Tue, Feb 19, 2013 at 4:15 AM, Jonathan <gamma_chen at yahoo.com.tw> wrote: > I check the Mips backend for the following C code fragment compile result. > It seems not correct. Is it my

I check the Mips backend for the following C code fragment compile result. It seems not correct. Is it my misunderstand or it's a bug. //ch8_3.cpp #include <stdarg.h> int sum_i(int amount, ...) { int i = 0; int val = 0; int sum = 0; va_list vl; va_start(vl, amount); for (i = 0; i < amount; i++) { val = va_arg(vl, int); sum += val; } va_end(vl);

Hi there, I'm still running 6.2 on various servers without any tweaks (GENERIC kernel, binary updates via freebsd-update etc.) but lots of ports (apache, postgresql, diablo-jdk etc.) and would like to use stack smashing protection in order to harden my boxes and avoid many potential exploits. I've known about ProPolice/SSP for a while now (from the Gentoo world) and am aware that

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to