F20 System Wide Change: ARM as primary Architecture

Carlos O'Donell carlos at redhat.com
Thu Jul 11 05:39:21 UTC 2013


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.



More information about the devel mailing list