[RFC][AArch64] Add support for system register based stack protector canary access
Ramana Radhakrishnan
Ramana.Radhakrishnan@arm.com
Mon Dec 3 09:55:00 GMT 2018
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.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sp_el0-patch.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20181203/f74c628b/attachment.txt>
More information about the Gcc-patches
mailing list