[PATCH] sched: move stack_canary to the start of the randomizable region

[PATCH] sched: move stack_canary to the start of the randomizable region

[Ruidong Tian]

task_struct keeps growing over time.  On architectures that compute the
per-task stack canary offset from asm-offsets.h and pass it to the
compiler via -mstack-protector-guard-offset=, this growth eventually
pushes stack_canary beyond what the target ISA can encode.

On RISC-V, canary loads are emitted as

    ld	t0, TSK_STACK_CANARY(tp)

where TSK_STACK_CANARY must fit into a 12-bit signed immediate, i.e.
[-2048, 2047].  Once stack_canary sits past byte 2047 of task_struct,
the build fails with

    cc1: error: '<N>' is not a valid offset in
        '-mstack-protector-guard-offset='

Move stack_canary to the very first slot of the randomizable region of
task_struct, right after __state / saved_state:

  * On RISC-V, CONFIG_STACKPROTECTOR_PER_TASK depends on !RANDSTRUCT,
    so randomized_struct_fields_start/end always expand to nothing and
    stack_canary lands at a small, stable offset well within the
    12-bit signed immediate range.  The build error goes away.

  * On architectures that enable RANDSTRUCT for hardening, stack_canary
    stays inside the randomized region and is still shuffled together
    with the other fields by the layout randomization, so its hardening
    coverage is preserved.  asm-offsets-based architectures read the
    shuffled offset at build time, so the generated canary accesses
    remain correct.

This is a refinement of Christophe Leroy's 2018 proposal [1], which
placed stack_canary before randomized_struct_fields_start and thereby
pulled it out of the randomized region entirely.  Michael Ellerman
flagged that at the time as a regression of the hardening coverage.
Keeping the field inside the region preserves the "scheduling-critical
items only" invariant documented above the start marker and retains
RANDSTRUCT protection on architectures that enable it.

[1]: https://lore.kernel.org/lkml/d60ce7dd74704b0ca0a857186f30de4006b63534.1537355312.git.christophe.leroy@c-s.fr/

Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com>
---
 include/linux/sched.h | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 368c7b4d7cb5..d9ee2381c3a3 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -836,6 +836,11 @@ struct task_struct {
 	 */
 	randomized_struct_fields_start
 
+#ifdef CONFIG_STACKPROTECTOR
+	/* Canary value for the -fstack-protector GCC feature: */
+	unsigned long			stack_canary;
+#endif
+
 	void				*stack;
 	refcount_t			usage;
 	/* Per task flags (PF_*), defined further below: */
@@ -1060,10 +1065,6 @@ struct task_struct {
 	pid_t				pid;
 	pid_t				tgid;
 
-#ifdef CONFIG_STACKPROTECTOR
-	/* Canary value for the -fstack-protector GCC feature: */
-	unsigned long			stack_canary;
-#endif
 	/*
 	 * Pointers to the (original) parent process, youngest child, younger sibling,
 	 * older sibling, respectively.  (p->father can be replaced with
-- 
2.51.2.612.gdc70283dfc

Re: [PATCH] sched: move stack_canary to the start of the randomizable region

[K Prateek Nayak]

Hello Ruidong,

On 5/8/2026 11:45 AM, Ruidong Tian wrote:
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 368c7b4d7cb5..d9ee2381c3a3 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -836,6 +836,11 @@ struct task_struct {
>          */
>         randomized_struct_fields_start
> 
> +#ifdef CONFIG_STACKPROTECTOR
> +       /* Canary value for the -fstack-protector GCC feature: */
> +       unsigned long                   stack_canary;
> +#endif

So I'm looking at pahole and I see the following on mainline
(v7.1-rc2):

struct task_struct {
        struct thread_info         thread_info;          /*     0    24 */
        unsigned int               __state;              /*    24     4 */
        unsigned int               saved_state;          /*    28     4 */
        void *                     stack;                /*    32     8 */
        refcount_t                 usage;                /*    40     4 */
        unsigned int               flags;                /*    44     4 */
        unsigned int               ptrace;               /*    48     4 */
        int                        on_cpu;               /*    52     4 */
        struct __call_single_node  wake_entry;           /*    56    16 */
        /* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */
        unsigned int               wakee_flips;          /*    72     4 */

        /* XXX 4 bytes hole, try to pack */

        long unsigned int          wakee_flip_decay_ts;  /*    80     8 */
        struct task_struct *       last_wakee;           /*    88     8 */
        int                        recent_used_cpu;      /*    96     4 */
        int                        wake_cpu;             /*   100     4 */
        int                        on_rq;                /*   104     4 */
        int                        prio;                 /*   108     4 */
        int                        static_prio;          /*   112     4 */
        int                        normal_prio;          /*   116     4 */
        unsigned int               rt_priority;          /*   120     4 */

        /* XXX 4 bytes hole, try to pack */

        /* --- cacheline 2 boundary (128 bytes) --- */

        ...
};


Except for alloc_tag, nothing in here is config dependent, and if we
move "wakee_flips" to after "last_wakee", we open up 8 bytes in this
cache line and "stack_canary" should be able to fit in there without
needing any additional space wrt to where we are at.

It'll look like:

struct task_struct {

        ...

        int                        on_cpu;               /*    52     4 */
        struct __call_single_node  wake_entry;           /*    56    16 */

        /* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */

        unsigned long              stack_canary;         /*    72     8 */
        long unsigned int          wakee_flip_decay_ts;  /*    80     8 */
        struct task_struct *       last_wakee;           /*    88     8 */
        unsigned int               wakee_flips;          /*    96     4 */

        ...
}


An offset of 72 bytes should be fine right? I doubt we'll ever add 2KB
worth of data in this area to worry about this again.

> +
>         void                            *stack;
>         refcount_t                      usage;
>         /* Per task flags (PF_*), defined further below: */
-- 
Thanks and Regards,
Prateek

Re: [PATCH] sched: move stack_canary to the start of the randomizable region

[Ruidong Tian]

在 2026/5/9 00:38, K Prateek Nayak 写道:
> An offset of 72 bytes should be fine right? I doubt we'll ever add 2KB
> worth of data in this area to worry about this again.

72 is definitely fine.

I'll take your suggestion for v2: move wakee_flips to after last_wakee
and drop stack_canary into the 8-byte slot at offset 72, keeping the
rest of the patch unchanged.

Thanks for the careful review!

Ruidong