Re: GCC stack protector with linux synthetic target

Hi Bart

Bart Veer wrote:

> Basically -fstack-protector depends on some extra work done by the
> glibc startup code. Of course the synthetic target does not use glibc
> so that extra bit of initialization does not happen. The extra init is
> not straightforward. It involves manipulating the x86 segment
> registers via a Linux system call. I could find no documentation for
> exactly what has to be done, and I could not immediately figure it out
> from the glibc sources. Straightforward copying from glibc is not
> acceptable either because of licensing issues.
> 
> Stack protection support was added to the compiler a few years back,
> offhand I don't know exactly when. However the default setting varies
> between distributions. Fedora and its ilk default to
> -fno-stack-protector, so everything just works. Debian and its ilk
> default to -fstack-protector, so things go wrong.
> 
> Possible solutions are:
> 
> 1) add -fno-stack-protector to the default flags for synth. This
> should work fine with all current distros. However it will break the
> world for anybody using an older distro where the gcc being used did
> not yet know about this compiler flag, or for anybody deliberately
> using an older gcc e.g. to use the same compiler version for synth and
> for real embedded targets. This was not really acceptable when we last
> looked at this. It may be more acceptable now, but is still not ideal.
> 
> 2) try to do some run-time detection to figure out whether or not
> -fno-stack-protector should be added. There are various complications,
> e.g. if people change the COMMAND_PREFIX setting.
> 
> 3) fix the problem properly by doing the segment register
> initialization. This should solve the problem irrespective of the
> distro or the version of gcc being used. It would also mean that the
> synthetic targets gains whatever benefits -fstack-protector offers.
> 
> Since I run Fedora on most of my systems I am not affected by any of
> this, so sorting it out is a low priority for me. If you want to look
> at option (3), that would be great. I would much prefer that to option
> (1), since if you go for that then there will never be any incentive
> to do the job properly.

Agreed. Thanks for the analysis. I have raised a bug report so this
doesn't get forgotten about:

  http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000801

There is also an issue with very old GCC:

  http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000723

John Dallaway