On Thu, Jan 10, 2019 at 11:05 AM Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Thu, Jan 10, 2019 at 10:53:32AM +0000, Ramana Radhakrishnan wrote:
> > > 2018-11-23  Ramana Radhakrishnan  <ramana.radhakrish...@arm.com>
> > >
> > >          * config/aarch64/aarch64-opts.h (enum stack_protector_guard): New
> > >          * config/aarch64/aarch64.c (aarch64_override_options_internal):
> > > Handle
> > >          and put in error checks for stack protector guard options.
> > >          (aarch64_stack_protect_guard): New.
> > >          (TARGET_STACK_PROTECT_GUARD): Define.
> > >          * config/aarch64/aarch64.md (UNSPEC_SSP_SYSREG): New.
> > >          (reg_stack_protect_address<mode>): New.
> > >          (stack_protect_set): Adjust for SSP_GLOBAL.
> > >          (stack_protect_test): Likewise.
> > >          * config/aarch64/aarch64.opt (-mstack-protector-guard-reg): New.
> > >          (-mstack-protector-guard): Likewise.
> > >          (-mstack-protector-guard-offset): Likewise.
> > >          * doc/invoke.texi: Document new AArch64 options.
> >
> > Any further thoughts or is it just Jakub's comments that I need to
> > address on this patch ? It looks like the kernel folks have queued
> > this for the next kernel release and given this is helping the kernel
> > with a security feature, can we move this forward ?
>
> From RM POV this is ok in stage4 if you commit it RSN.
> Both x86 and powerpc have -mstack-protector-guard{,-reg,-offset}= options,
> x86 even has -mstack-protector-guard-symbol=.  So it would be nice if the
> aarch64 options are compatible with those other arches.
>

Thanks Jakub. I haven't added the -mstack-protector-guard-symbol as
there is no requirement to do so now and I don't want to add an option
that isn't being used. IIRC, the other options seem to be in sync with
x86 and powerpc.

> Please make sure you don't regress non-glibc SSP support (don't repeat
> PR85644/PR86832).
>

That should be ok as I'm not changing any defaults. I would expect
that non-glibc based libraries that support SSP must be mimicking
glibc support for this using the global symbol as there is nothing
special in the backend for this today. I guess there is freebsd as a
non-glibc target or musl that I can look at but I don't expect that to
be an issue.

I'll wait until tomorrow to respin just to see if I can get any
further feedback.

regards
Ramana



>         Jakub

Reply via email to