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

[Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>]

On 10/01/2019 15:49, James Greenhalgh wrote:
> On Mon, Dec 03, 2018 at 03:55:36AM -0600, Ramana Radhakrishnan 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 ?
> 
> I didn't see ananswer on list to Ard's questions about the command-line logic.

Ah I must have missed that - will take that up separately.

> Remember to also fix up the error message concerns Florian raised.
> 


> That said, if Jakub is happy with this in Stage 4, I am too.
> 
> My biggest concern is the -mstack-protector-guard-reg interface, which
> is unchecked user input and so opens up nasty ways to force the compiler
> towards out of bounds accesses (e.g.
> -mstack-protector-guard-reg="What memory is at %10")
> 

-mstack-protector-guard-reg is fine - it's a system register , if the 
assembler doesn't recognize it , it will barf.

-mstack-protector-guard-offset=<offset> I assume is what you are 
concerned about. I don't have a good answer to that one and am going to 
chicken out and say this is the same interface as x86 and power and 
while I accept it's an access to any location, the user can still do 
that with a C program and any arbitrary inline asm :-/



regards
Ramana

> Thanks,
> James
> 
>>
>> 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.
>