From nobody Sat May 30 12:35:57 2026 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F72435A3A9 for ; Fri, 8 May 2026 06:16:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.113 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778220978; cv=none; b=qOX3HeJxoMnrL+Am8oeME5cgmfQYCzVRAhOfpshf4yaM8PqXebCY4Ix8RPMx8ZaQdhpUOPsKpzL+hcXta8eB1xUVl+4O1n4mS/Gbw9Oqd3Coc1z4JNl88ASb+x32aQTDxBwnWgbwmb6i89KaI4vjFsgobxNSsLfgmnrVV/xGz9M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778220978; c=relaxed/simple; bh=i9LRJ+3v+C/NQmUBusrGpUiAs3e0TNQ94AIDfJZ0ZUE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=IKUaYVYxRJrzHz5vu26R5c43F7wda8/kTUEh0RIad+9qXKlxGxZdR5tnwfVNp6roA5FyVbZT0PNIWEfvCQzxAllPbwmA7Y7MITEqHhXgGsRPUYBrHP+L4yb3pn+nrbulmg+4Pzwf1GVdVKOVMviasDyUIw0as9BfW7dk4iqQX5s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=NbFxJmoy; arc=none smtp.client-ip=115.124.30.113 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="NbFxJmoy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1778220962; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=c99GrysCBJcK9ZkCcvWPoyrwLiY96iX+9O8F6UlK9e0=; b=NbFxJmoybFKwkWoofuqm/08Fb+xCUo7x0vncblTepgAPFyPetshJC10edZ5c77VaDhemLMMZr3Sa7FWkynVV7AxUGE3pICCYAqzTmUu/89OvwiYpmrL8XU6VruOQy1Qm6NauwmYj9kjXfbU6Dn6gQBqSK+JPn5X7aG2pMZx7pqQ= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R671e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam011083073210;MF=tianruidong@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0X2WYTBq_1778220959; Received: from t50a05405.sqa.eu95.tbsite.net(mailfrom:tianruidong@linux.alibaba.com fp:SMTPD_---0X2WYTBq_1778220959 cluster:ay36) by smtp.aliyun-inc.com; Fri, 08 May 2026 14:16:02 +0800 From: Ruidong Tian To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com Cc: linux-kernel@vger.kernel.org, oliver.yang@linux.alibaba.com, Ruidong Tian Subject: [PATCH] sched: move stack_canary to the start of the randomizable region Date: Fri, 8 May 2026 14:15:58 +0800 Message-ID: <20260508061558.2976364-1-tianruidong@linux.alibaba.com> X-Mailer: git-send-email 2.43.7 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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=3D, 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: '' is not a valid offset in '-mstack-protector-guard-offset=3D' 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 --- 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 =20 +#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; =20 -#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 sib= ling, * older sibling, respectively. (p->father can be replaced with --=20 2.51.2.612.gdc70283dfc