On Mon, 2016-08-22 at 09:02 +0100, André Draszik wrote: > On Fr, 2016-08-19 at 19:46 +0100, Joshua G Lock wrote: > > > > On Fri, 2016-08-19 at 10:07 -0700, Khem Raj wrote: > > > > > > > > > > > > > > > > > > > > > > On Aug 19, 2016, at 8:34 AM, Joshua Lock <[email protected] > > > > om> > > > > wrote: > > > > > > > > This tells the compiler to use a canary to protect any function > > > > which > > > > declares a character array of 4 or more bytes on its stack, > > > > rather > > > > than the default of 8 or more bytes. > > > > > > Thats fine, however, it slows down the code, strong option was a > > > compromise > > > otherwise we could just use fstack-protector-all > > > > It's my understanding that the ssp-buffer-size parameter changes > > the > > size of buffer the base, fstack-protector, protections affect and > > that > > the performance impact is less significant than adding protections > > to > > all functions via stack-protector-all? > > I understand it as follows instead: > > --param=ssp-buffer-size=X only makes sense together with -fstack- > protector, as -fstack-protector can to be configured for the minimum > size of arrays to protect (8 by default, if --param=ssp-buffer-size= > is not given). > > --param=ssp-buffer-size=X does not make sense with -fstack-protector- > strong as this version protects arrays of *any* size anyway. > > https://gcc.gnu.org/ml/gcc-patches/2012-06/msg00974.html > -> This also has the design doc towards the end. > https://lwn.net/Articles/584225/ > > So I don't think this patch is needed at all...
Thanks for the link, having read the patch and design doc I'm inclined to agree. > > > > FWIW, the related options in Fedora and Ubuntu: > > > > * Ubuntu: -fstack-protector --param=ssp-buffer-size=4 (default in > > hardened builds) > > * Fedora: -fstack-protector-strong --param=ssp-buffer-size=4 > > (default > > in all builds) > > Debian (sid) uses -fstack-protector-strong (without ssp-buffer-size). > Thanks, I couldn't find a Debian system on Friday evening. Regards, Joshua -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
