On 07/10/2013 01:36 PM, Jakub Jelinek wrote: > On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote: >> armv7 has stack protector, aarch64 which is outside of this proposal >> doesnt yet have it. > > Only i?86/x86_64/ppc/ppc64/s390/s390x/sparc/sparc64/tilegx/tilepro > really have full stack protector support, while perhaps -fstack-protector > doesn't error out on armv7, it certainly isn't supported in glibc > (neither TLS stack guard, not TLS pointer guard), so I wouldn't talk about > arm having security standards high enough for being a primary architecture. > > CCing Carlos so that they can discuss that.
Without specific support for stack protector (TLS stack guard and TLS pointer guard) the glibc build will fall back to exporting two symbols for use by libssp e.g. __stack_chk_guard, and __pointer_chk_guard. They serve a similar purpose to the TLS variables but are global. Thus I would expect -fstack-protector to work with libssp on 32-bit ARM, but I haven't verified that. Even with that support the 32-bit ARM port of glibc lacks proper pointer mangling/demangling routines so it doesn't make use of the __pointer_chk_guard value. In summary: - I would expect -fstack-protector to work on 32-bit ARM via libssp and support stack guards but not pointer guards (for pointer mangling). Next steps: - Verify libssp works correctly on 32-bit ARM. - Look at enhancing the existing support in glibc. - Add TLS stack guard. - Add TLS pointer guard. - Add pointer mangle/demangle support. - Enhance aarch64 to support the same set of features. The glibc team doesn't have any immediate plans to implement any of this. Cheers, Carlos. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
