From nobody Fri Apr 17 13:47:56 2026 Received: from smtpout.efficios.com (smtpout.efficios.com [158.69.130.18]) (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 A8FDF34847A for ; Wed, 18 Feb 2026 20:14:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=158.69.130.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771445658; cv=none; b=R10332VeMONIwnFVWn9IEhqU6yxX3EWmTcgMiNHQPdt3Gi7GwwRzgcCgx28oIB1XXHd/ZLTlpRU+z3OoaFPwFhh+Sjumh2scGPnWie1Gtx6Y43Et2x+yChvyCtNX6EacvRJxGAN9FQ0RZMghF1kNhLIS2PBCwtJm0Z0Ak5rrf48= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771445658; c=relaxed/simple; bh=L1wLMHI0oI0LjxHlc2YwsZo354xzGirQ7xFxSyvfON0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=VVr8CtqUUFcwuJDUFepzWmsLcNUiaRjTNsgldPhAmmCz8fJ8xh224W0BhJYp/t4SaoaahHbDswhR5TnDOacT5nZq3bdsc3W7H8DjxSn5+6wbkWbbDrefruuZW/ea5g7o15z46ZPJDTcRmYWq2QYh62g74Jw3dWYwxeRCh7v4UjI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com; spf=pass smtp.mailfrom=efficios.com; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b=J57E5L8a; arc=none smtp.client-ip=158.69.130.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=efficios.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="J57E5L8a" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=smtpout1; t=1771445656; bh=NnvSvLNsHWWpbpKQkIRk4qePKv6sL5zIgZ0CeBrrNOg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=J57E5L8a7bMZ+enodrXl//c+EWqkXUYwxJXzIWN14ALQcGRhN+FI9vWWQ2bElZQB6 vgqWAiobj+LACmxSP9hmft+wbHkG70Wb0QGRTD/+N24HwzBBW+Hqpd+rf6UbNjI6WU 04BUg0+MN3bSNATJnlIm4o0CAF7XbQckUXmFBncAjBkWQ+O3/KIRDA1XhonU3IcyVY 17vpBkhddV18pN6YNj+q7RSpckju1xA0/1asWxLrzhAc3vJE6EzDbIhMLWrxPSpH/j j1SaZ8u3+6oySx3P7q0WjCqX4b2LKGABWyKRtnY8bR20oBr+dTNqbO2yR3zCEjXJhh 4mKHjQIs+yhfA== Received: from thinkos.internal.efficios.com (mtl.efficios.com [216.120.195.104]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4fGSQc5MM3zG45; Wed, 18 Feb 2026 15:14:16 -0500 (EST) From: Mathieu Desnoyers To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, Mathieu Desnoyers , Ingo Molnar , Thomas Gleixner , Carlos O'Donell , Florian Weimer , Michael Jeanson Subject: [PATCH v2 1/2] rseq: Clarify rseq registration rseq_size bound check comment Date: Wed, 18 Feb 2026 15:14:12 -0500 Message-Id: <20260218201413.1187745-2-mathieu.desnoyers@efficios.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260218201413.1187745-1-mathieu.desnoyers@efficios.com> References: <20260218201413.1187745-1-mathieu.desnoyers@efficios.com> 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" The rseq registration validates that the rseq_size argument is greater or equal to 32 (the original rseq size), but the comment associated with this check does not clearly state this. Clarify the comment to that effect. Fixes: ee3e3ac05c26 ("rseq: Introduce extensible rseq ABI") Signed-off-by: Mathieu Desnoyers CC: Peter Zijlstra (Intel) CC: Ingo Molnar CC: Thomas Gleixner --- kernel/rseq.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/rseq.c b/kernel/rseq.c index b0973d19f366..e349f86cc945 100644 --- a/kernel/rseq.c +++ b/kernel/rseq.c @@ -449,8 +449,9 @@ SYSCALL_DEFINE4(rseq, struct rseq __user *, rseq, u32, = rseq_len, int, flags, u32 * auxiliary vector AT_RSEQ_ALIGN. If rseq_len is the original rseq * size, the required alignment is the original struct rseq alignment. * - * In order to be valid, rseq_len is either the original rseq size, or - * large enough to contain all supported fields, as communicated to + * The rseq_len is required to be greater or equal to the original rseq + * size. In order to be valid, rseq_len is either the original rseq size, + * or large enough to contain all supported fields, as communicated to * user-space through the ELF auxiliary vector AT_RSEQ_FEATURE_SIZE. */ if (rseq_len < ORIG_RSEQ_SIZE || --=20 2.39.5 From nobody Fri Apr 17 13:47:56 2026 Received: from smtpout.efficios.com (smtpout.efficios.com [158.69.130.18]) (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 A8F6934846C for ; Wed, 18 Feb 2026 20:14:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=158.69.130.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771445659; cv=none; b=MMCoQr//mvC7yNqWUsF1iMRgZmLWZrMiMC5SQtP0SlIgnlTRKSzieXsxU2ZWx+nTiARRsESSclxk5kLilza02lCOcmhLjyR6jNDKxVineSEzJypOgS3+2ktxjLUTtPrD9SMqNL3/KszFBnwjqV/8hjDJW5ZYbbUVcu3N5F9C9/U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771445659; c=relaxed/simple; bh=O0y+6l95RDMdLPGudbl+V5pHmfBRIo0W/GiUtYeu07c=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=VJhGXAM+69UQl/B8Fj20MUDSxO8giPM68Xnud4KTlApkGStvEg6kXc5RsMoh/VqGSx1lIEshoar/3gQvqiwzy6+35ui8hE4v+mypBhy3R8m8f4cWLC4dg6lHGZFkCyXHl7/Gt6pBDzSYuwDZJju6CSTEH71GX6deiXK8R3pMOic= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com; spf=pass smtp.mailfrom=efficios.com; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b=GQStdKNK; arc=none smtp.client-ip=158.69.130.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=efficios.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="GQStdKNK" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=smtpout1; t=1771445656; bh=akWahYcZXJ0jdDYYbT49amIX6oqq6xsIfeRCHAJRNA0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GQStdKNK4eZ4+3iqCrj8NjaQIaaN8qQviYhGrPvHbeY7gWdunsfgggbePPXLsgAJZ 6vl4SPXr+L8bnipjXz5vF+SAdh3jOt/0cYn7m65uwZQtHghw8UnpJGKfE4bJkRecIS zJmn1VBayoIhrFU90tx0wVS+ZSVVTzBuRYn3kUhfrHsVaeWq9/k1qPG3JP0p1ed35w hz2C6AMpBtbGtsq8JvhZ8hH+2Wd3BFW42gkxvG4pf7iAYxLHvRbfbNIK1x1nSEKMY+ 3OL4H9OA+SDC/NfExUDXbiyXB33Luferm34P/0ZCMdewuZLkgqeBoPNre0Tpk3X3YV JEYX9FA0Pd7ig== Received: from thinkos.internal.efficios.com (mtl.efficios.com [216.120.195.104]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4fGSQc6DlxzFsQ; Wed, 18 Feb 2026 15:14:16 -0500 (EST) From: Mathieu Desnoyers To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, Mathieu Desnoyers , Ingo Molnar , Thomas Gleixner , Carlos O'Donell , Florian Weimer , Michael Jeanson Subject: [PATCH v2 2/2] rseq: slice ext: Ensure rseq feature size differs from original rseq size Date: Wed, 18 Feb 2026 15:14:13 -0500 Message-Id: <20260218201413.1187745-3-mathieu.desnoyers@efficios.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260218201413.1187745-1-mathieu.desnoyers@efficios.com> References: <20260218201413.1187745-1-mathieu.desnoyers@efficios.com> 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" Before rseq became extensible, its original size was 32 bytes even though the active rseq area was only 20 bytes. This had the following impact in terms of userspace ecosystem evolution: * The GNU libc between 2.35 and 2.39 expose a __rseq_size symbol set to 32, even though the size of the active rseq area is really 20. * The GNU libc 2.40 changes this __rseq_size to 20, thus making it express the active rseq area. * Starting from glibc 2.41, __rseq_size corresponds to the AT_RSEQ_FEATURE_SIZE from getauxval(3). This means that users of __rseq_size can always expect it to correspond to the active rseq area, except for the value 32, for which the active rseq area is 20 bytes. Exposing a 32 bytes feature size would make life needlessly painful for userspace. Therefore, add a reserved field at the end of the rseq area to bump the feature size to 33 bytes. This reserved field is expected to be replaced with whatever field will come next, expecting that this field will be larger than 1 byte. The effect of this change is to increase the size from 32 to 64 bytes before we actually have fields using that memory. We cannot change the alignment of struct rseq (originally 32 bytes) because the kernel should be able to interact with a userspace which aligns its struct rseq only on 32 bytes. Clarify this in the rseq uapi with a comment. Change the value returned by getauxval(AT_RSEQ_ALIGN) to return the value of the active rseq area size rounded up to next power of 2, which guarantees that the rseq structure will always be aligned on the nearest power of two large enough to contain it, even as it grows. Change the alignment check in the rseq registration accordingly. This will minimize the amount of ABI corner-cases we need to document and require userspace to play games with. The rule stays simple when __rseq_size !=3D 32: #define rseq_field_available(field) (__rseq_size >=3D offsetofend(struct = rseq_abi, field)) Signed-off-by: Mathieu Desnoyers CC: Peter Zijlstra (Intel) CC: Ingo Molnar CC: Thomas Gleixner CC: Carlos O'Donell CC: Florian Weimer CC: Michael Jeanson --- fs/binfmt_elf.c | 3 ++- include/linux/rseq.h | 12 ++++++++++++ include/uapi/linux/rseq.h | 19 ++++++++++++++++--- kernel/rseq.c | 3 ++- 4 files changed, 32 insertions(+), 5 deletions(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 3eb734c192e9..84c74b731b8c 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -47,6 +47,7 @@ #include #include #include +#include #include #include =20 @@ -286,7 +287,7 @@ create_elf_tables(struct linux_binprm *bprm, const stru= ct elfhdr *exec, } #ifdef CONFIG_RSEQ NEW_AUX_ENT(AT_RSEQ_FEATURE_SIZE, offsetof(struct rseq, end)); - NEW_AUX_ENT(AT_RSEQ_ALIGN, __alignof__(struct rseq)); + NEW_AUX_ENT(AT_RSEQ_ALIGN, rseq_alloc_align()); #endif #undef NEW_AUX_ENT /* AT_NULL is zero; clear the rest too */ diff --git a/include/linux/rseq.h b/include/linux/rseq.h index 7a01a0760405..b9d62fc2140d 100644 --- a/include/linux/rseq.h +++ b/include/linux/rseq.h @@ -146,6 +146,18 @@ static inline void rseq_fork(struct task_struct *t, u6= 4 clone_flags) t->rseq =3D current->rseq; } =20 +/* + * Value returned by getauxval(AT_RSEQ_ALIGN) and expected by rseq + * registration. This is the active rseq area size rounded up to next + * power of 2, which guarantees that the rseq structure will always be + * aligned on the nearest power of two large enough to contain it, even + * as it grows. + */ +static inline unsigned int rseq_alloc_align(void) +{ + return 1U << get_count_order(offsetof(struct rseq, end)); +} + #else /* CONFIG_RSEQ */ static inline void rseq_handle_slowpath(struct pt_regs *regs) { } static inline void rseq_signal_deliver(struct ksignal *ksig, struct pt_reg= s *regs) { } diff --git a/include/uapi/linux/rseq.h b/include/uapi/linux/rseq.h index 863c4a00a66b..d5b3c489901e 100644 --- a/include/uapi/linux/rseq.h +++ b/include/uapi/linux/rseq.h @@ -87,8 +87,10 @@ struct rseq_slice_ctrl { }; =20 /* - * struct rseq is aligned on 4 * 8 bytes to ensure it is always - * contained within a single cache-line. + * The alignment of struct rseq used by the kernel needs to be 32 bytes + * so the kernel can interact with legacy userspace which allocate + * struct rseq with its original alignment. + * Userspace aligns struct rseq allocation on 32 bytes or more. * * A single struct rseq per thread is allowed. */ @@ -180,10 +182,21 @@ struct rseq { */ struct rseq_slice_ctrl slice_ctrl; =20 + /* + * Before rseq became extensible, its original size was 32 bytes even + * though the active rseq area was only 20 bytes. + * Exposing a 32 bytes feature size would make life needlessly painful + * for userspace. Therefore, add a reserved byte after byte 32 + * to bump the rseq feature size from 32 to 33. + * The next field to be added to the rseq area will be larger + * than one byte, and will replace this reserved byte. + */ + __u8 __reserved; + /* * Flexible array member at end of structure, after last feature field. */ char end[]; -} __attribute__((aligned(4 * sizeof(__u64)))); +} __attribute__((aligned(32))); =20 #endif /* _UAPI_LINUX_RSEQ_H */ diff --git a/kernel/rseq.c b/kernel/rseq.c index e349f86cc945..38d3ef540760 100644 --- a/kernel/rseq.c +++ b/kernel/rseq.c @@ -80,6 +80,7 @@ #include #include #include +#include #include =20 #define CREATE_TRACE_POINTS @@ -456,7 +457,7 @@ SYSCALL_DEFINE4(rseq, struct rseq __user *, rseq, u32, = rseq_len, int, flags, u32 */ if (rseq_len < ORIG_RSEQ_SIZE || (rseq_len =3D=3D ORIG_RSEQ_SIZE && !IS_ALIGNED((unsigned long)rseq, O= RIG_RSEQ_SIZE)) || - (rseq_len !=3D ORIG_RSEQ_SIZE && (!IS_ALIGNED((unsigned long)rseq, __= alignof__(*rseq)) || + (rseq_len !=3D ORIG_RSEQ_SIZE && (!IS_ALIGNED((unsigned long)rseq, rs= eq_alloc_align()) || rseq_len < offsetof(struct rseq, end)))) return -EINVAL; if (!access_ok(rseq, rseq_len)) --=20 2.39.5