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.
Sent from my iPad
On Jul 10, 2013, at 19:40, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Wed, Jul 10, 2013 at 6:36 PM, Jakub Jelinek
> 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).
devel mailing list