F20 System Wide Change: ARM as primary Architecture

Jonathan Masters jcm at redhat.com
Thu Jul 11 01:53:09 UTC 2013


That option simply preserves the global stack canary value between tasks during context switch. It's not really core to this. The core piece is userspace compiler tooling. I know the option exists and I thought/was lead to believe it works. But if Jakub has concerns I will add that to the feedback I have already raised with ARM/Linaro here in Dublin this evening.

But also guys, come on. We can't be having random new requirements being added in a bike shedding exercise with the first this being raised happening now. If there are issues then they can be prioritized and worked on, but we'll never get anywhere if things are raised in this manner. As I see it, ARM is the most popular architecture on Earth, is damn well supported in Fedora, and we do the Fedora community a disservice by not bringing the 4 F's into this and thinking about the broader context. So, I'll/we'll come back with more data on the stack protector implementation and what we can do about llvmpipe, but meanwhile please give us useful guidance on what you actually want for ARM to be a PA. Not "hand wavy it must be feature parity with x86". I can think of plenty of terrible things x86 does that I would never want to see ARM attempt to match.

Jon.

-- 
Sent from my iPad

On Jul 10, 2013, at 19:40, Peter Robinson <pbrobinson at gmail.com> wrote:

> On Wed, Jul 10, 2013 at 6:36 PM, Jakub Jelinek <jakub at redhat.com> 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.
> 
> So what does the kernel level CC_STACKPROTECTOR config option bring to
> this as it appears to be associated with the -fstack-protector option
> as well (according to it's Kconfig description) but is only supported
> on x86/arm from that list above (plus sh).
> 
> Peter
> -- 
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


More information about the devel mailing list