On Thu, Jun 29, 2017 at 3:53 PM, Kees Cook <keesc...@chromium.org> wrote: > I see a few possible solutions:
Or this ugly hack: diff --git a/include/linux/sched.h b/include/linux/sched.h index e2ad3531e7fe..5d131f9f1dac 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -749,6 +749,19 @@ struct task_struct { /* Namespaces: */ struct nsproxy *nsproxy; +#ifdef CONFIG_ARM + /* + * Since task_struct is gigantic, some asmoffset locations + * (e.g. TSK_STACK_CANARY) for a randomized field may exceed + * an architecture's instruction immediate values. As a + * work-around to avoid changing the performance characteristics + * of the assembly, split the randomization into two groups, + * keeping the "early" fields within range of the immediates. + */ + randomized_struct_fields_end + randomized_struct_fields_start +#endif + /* Signal handlers: */ struct signal_struct *signal; struct sighand_struct *sighand; I suspect updating the ARM assembly (CONFIG-conditionally) to accept >4095 offsets is probably the best solution. -Kees -- Kees Cook Pixel Security