On Mon, Jun 19, 2017 at 10:33:26AM -0400, Bryan Steele wrote: > On Sat, Jun 17, 2017 at 12:58:03PM +0100, Stuart Henderson wrote: > > On 2017/06/04 04:40, Bryan Steele wrote: > > > "As Shmuel reported in > > > <https://gcc.gnu.org/ml/gcc-help/2017-03/msg00009.html>, > > > on x86-64 small structures in automatic storage are aligned to 16 bytes. > > > This seems to be because of a mix-up between bits and bytes in the i386 > > > target code. > > > > > > * config/i386/i386.c (ix86_local_alignment): Align most aggregates > > > of 16 bytes and more to 16 bytes, not those of 16 bits and more." > > > > > > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b44e9be23d38be8997ae64d7509ac22cb4c556d6 > > > > > > It might be worth fixing this in ports gcc 4.9, found by tedu@ in 2014 > > > and committed by martynas@ to base gcc4 shortly later. > > > > > > http://www.tedunangst.com/flak/post/my-stack-protector-wasnt-working > > > http://marc.info/?l=openbsd-cvs&m=139895377300712&w=2 > > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/gcc/gcc/config/i386/i386.c.diff?r1=1.3&r2=1.4&f=h > > > > Does this actually work? > > > > I might be missing something from this, but I haven't been able to > > elicit a SIGABRT from Ted's simple test program with any of the > > compilers. > > > > Any idea what's going on? > > > > $ for i in gcc egcc /usr/bin/clang /usr/local/bin/clang; do printf "$i\t"; > > $i -o scanf scanf.c; echo 12345678901234567890123456789012 | ./scanf; done > > gcc 12345678901234567890123456789012 0xabad1dea > > egcc 12345678901234567890123456789012 0xabad1dea > > /usr/bin/clang 12345678901234567890123456789012 0xabad1dea > > /usr/local/bin/clang 12345678901234567890123456789012 0xabad1dea > > It works with the example I gave previously, at least, I can't find > tedu@'s example, but there is always the possibility for alignment > or padding differences preventing it from reproducibly triggering > on every overflow. > > http://marc.info/?l=openbsd-ports&m=149667837410983&w=2 > > $ pkg_info | grep gcc > gcc-4.9.4p5 GNU compiler collection: core C compiler > $ egcc ssp-test.c -o ssp-test-egcc > $ ./ssp-test-egcc > Abort trap > > Of course, there could *always* be more compiler bugs.. ;-) > > -Bryan.
Found it http://undeadly.org/cgi?action=article&sid=20131202075805 A good explanation from otto@ in the comments, as others reported this before.. "Stack protection only protects the return address and frame pointer. There's no way it will catch any stack based overflow. Due to alignment rules on amd64, the buffer will live further in the stack frame, hence the one byte overflow just falls into the alignment gap. i386 allows it's stack frame to be packed tight." http://undeadly.org/cgi?action=article&sid=20131202075805&pid=6 -Bryan.
