For quite sometime the kernel guys, (more specifically Ard) have been 
talking about using a system register (sp_el0) and an offset from that 
for a canary based access. This patchset adds support for a new set of
command line options similar to how powerpc has done this.

I don't intend to change the defaults in userland, we've discussed this 
for user-land in the past and as far as glibc and userland is concerned 
we stick to the options as currently existing. The system register 
option is really for the kernel to use along with an offset as they 
control their ABI and this is a decision for them to make.

I did consider sticking this all under a mcmodel=kernel-small option but
thought that would be a bit too aggressive. There is very little error
checking I can do in terms of the system register being used and really
the assembler would barf quite quickly in case things go wrong. I've
managed to rebuild Ard's kernel tree with an additional patch that
I will send to him. I haven't managed to boot this kernel.

There was an additional question asked about the performance 
characteristics of this but it's a security feature and the kernel 
doesn't have the luxury of a hidden symbol. Further since the kernel 
uses sp_el0 for access everywhere and if they choose to use the same 
register I don't think the performance characteristics would be too bad, 
but that's a decision for the kernel folks to make when taking in the 
feature into the kernel.

I still need to add some tests and documentation in invoke.texi but
this is at the stage where it would be nice for some other folks
to look at this.

The difference in code generated is as below.

extern void bar (char *);
int foo (void)
{
   char a[100];
   bar (&a);
}

$GCC -O2  -fstack-protector-strong  vs 
-mstack-protector-guard-reg=sp_el0 -mstack-protector-guard=sysreg 
-mstack-protector-guard-offset=1024 -fstack-protector-strong

	
--- tst.s	2018-12-03 09:46:21.174167443 +0000
+++ tst.s.1	2018-12-03 09:46:03.546257203 +0000
@@ -15,15 +15,14 @@
  	mov	x29, sp
  	str	x19, [sp, 16]
  	.cfi_offset 19, -128
-	adrp	x19, __stack_chk_guard
-	add	x19, x19, :lo12:__stack_chk_guard
-	ldr	x0, [x19]
-	str	x0, [sp, 136]
-	mov	x0,0
+	mrs	x19, sp_el0
  	add	x0, sp, 32
+	ldr	x1, [x19, 1024]
+	str	x1, [sp, 136]
+	mov	x1,0
  	bl	bar
  	ldr	x0, [sp, 136]
-	ldr	x1, [x19]
+	ldr	x1, [x19, 1024]
  	eor	x1, x0, x1
  	cbnz	x1, .L5




I will be afk tomorrow and day after but this is to elicit some comments 
and for Ard to try this out with his kernel patches.

Thoughts ?

regards
Ramana

gcc/ChangeLog:

2018-11-23  Ramana Radhakrishnan  <ramana.radhakrishnan@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.