[RFC][AArch64] Add support for system register based stack protector canary access

[Ramana Radhakrishnan]

On Mon, Dec 3, 2018 at 9:55 AM Ramana Radhakrishnan
<Ramana.Radhakrishnan@arm.com> wrote:
>
> 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.

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 ?

Ramana