[PATCH] arm64: Add CONFIG_CC_STACKPROTECTOR

[Nicolas Pitre]

On Wed, 22 Jan 2014, Laura Abbott wrote:
> On 1/22/2014 3:28 AM, Will Deacon wrote:
> > On Tue, Jan 21, 2014 at 05:26:06PM +0000, Laura Abbott wrote:
> > > @@ -288,6 +294,9 @@ struct task_struct *__switch_to(struct task_struct
> > > @@ *prev,
> > >   {
> > >    struct task_struct *last;
> > >
> > > +#if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
> > > +	__stack_chk_guard = next->stack_canary;
> > > +#endif
> >
> > I don't get the dependency on !SMP. Assumedly, the update of
> > __stack_chk_guard would be racy otherwise, but that sounds solvable with
> > atomics. Is the stack_canary updated periodically somewhere else?
> >
> 
> It has nothing to do with atomics, it's the fact that __stack_chk_guard is a
> global variable and with SMP you can have n different processes running each
> with a different canary (see kernel/fork.c, dup_task_struct) . c.f the commit
> added by Nicolas Pitre:
> 
> commit df0698be14c6683606d5df2d83e3ae40f85ed0d9
> Author: Nicolas Pitre <nico at fluxnic.net>
> Date:   Mon Jun 7 21:50:33 2010 -0400
> 
>     ARM: stack protector: change the canary value per task
> 
>     A new random value for the canary is stored in the task struct whenever
>     a new task is forked.  This is meant to allow for different canary 
> values
>     per task.  On ARM, GCC expects the canary value to be found in a global
>     variable called __stack_chk_guard.  So this variable has to be updated
>     with the value stored in the task struct whenever a task switch occurs.
> 
>     Because the variable GCC expects is global, this cannot work on SMP
>     unfortunately.  So, on SMP, the same initial canary value is kept
>     throughout, making this feature a bit less effective although it is 
> still
>     useful.
> 
>     One way to overcome this GCC limitation would be to locate the
>     __stack_chk_guard variable into a memory page of its own for each CPU,
>     and then use TLB locking to have each CPU see its own page at the same
>     virtual address for each of them.
> 
>     Signed-off-by: Nicolas Pitre <nicolas.pitre at linaro.org>

Did gcc for Aarch64 replicate the same global variable arrangement?
That would be unfortunate...


Nicolas