From nobody Fri Dec 19 04:49:40 2025 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8620020B80A for ; Fri, 21 Feb 2025 13:57:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740146237; cv=none; b=cbdYQ2j9zW9jztuhyGbBzV/kLMBQPkavUoucm+6Zev8lWLIxiNEuvC/88FEecqssgxohyXMNp8MmO1TB88t9UIzKY82/ZIju3hB3WOPj+jQWys9TAfPWKyWxbqBlNI5es+y32j6TKXTB0NjgU6vd+CpjDUbVKjbkU/VEFbJXduY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740146237; c=relaxed/simple; bh=volPFa9RYy4gVcRgv7Kf3SiRUiDUxttAzs4dh4Ct8Vs=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=J7TAnQ0caUfHyaOwG03ulvqje58cVFTond9dHtK47794kXOIRmHRNIIRSP0KpHnELEdHJuXXjCOFDGQXx2+ld5QgbfwS7c4JM4+hCn3hv2M7ZnH8EiSHc/316Af9Dd/fy8CfSmPkHIBr49H+jFYIi2tmQPd8GtEe2ZJq+GOtQVs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--ardb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=IObDNwlc; arc=none smtp.client-ip=209.85.128.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--ardb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="IObDNwlc" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-43995bff469so23026665e9.2 for ; Fri, 21 Feb 2025 05:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740146234; x=1740751034; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=0QgqpJEuycUIEe4Og2qawQLjpg/faFxO4eXm0mFbcOA=; b=IObDNwlcrRwXS//K+defeDYPobCM6RWgSCfbh81CsfNrPKJz14I/KyLcx5qYpffOEX /JzW6Ud4us/FxKknkitYizgvEUANFNGDb75LVhZ7nGUyoODZ802RHAuFk9oZ8N7NTQc3 hQJtYg2nnxLVB2QbgNa++S1Rt7nTjP8OURxYwSnB3eWB6lYa2zvGtKw0yWkNjyAOsrH1 W3zEsPjYsoD8YZ2kb+6xCUoG1JzdwgbLihnKrkPKHL/QzOZ6rxD7DYcBKrCbges9WY58 GF4CjdeI/tzXqy0WAtU7Q1AcOuGHpJkVS3/99bX8VsqZ4Pd5DL+d2Kn3NBQ0aYDchx/E Mf9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740146234; x=1740751034; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0QgqpJEuycUIEe4Og2qawQLjpg/faFxO4eXm0mFbcOA=; b=xCcFi7ofTDqCJX0JljggNl2hwJ2DVbIS6az4npqZjlSUcmiYq+FpsMVOqPvmqsxje2 C0U4fbKD2Ga3eSBeKhEX+rayfJ9c2oZeZo0keETQMw9nVPsfA0fQOkC/XFaUPMUx0qff AxW7HiygoV84A98A38fBUOrajYPeGQZMXhJM2IOJLm4drz+L4Qr2H4KjnzJYdG0PoeqD 8at8qTVfTpn0CEqqVXYN7xfFG0mDCvDOpFdoQyPSmbtzeUAmN93kHpMjET+fsIn3Iivh w4TviaVkB23GJafGOnR4VvRcybpTIRagXkmk+Wkiij9KkZKXLiK64kXlqPoHC80BnbyW Vhrw== X-Gm-Message-State: AOJu0YwPnE6onWHlmgpfbmC+LnUxt5ikDrf279eZRCBEZ6+iYK71jRLR vSgddDWnULVAClYJk9IIPcwtNjXj2MqDLRc9jqGzX/M+LrdAXgn61NkY1Dq0slu2EoQ7xw/jJ86 z7opJQ1xuCCeZB8qD3/hs+myxSZf7hRj0VS6scU0ZXsb8Rd26QRr/dYdzwF67NJXvrqd038JMsN YGJ2bnI5wU4HfGG2jif4m+tLHfXQxukA== X-Google-Smtp-Source: AGHT+IGx6LVhgSFcm42dg7VjXDgeanxRd6Hh/hW3ioF0J+rcD6X8uxvpf66q7lnwBitra9fBYMtRkJ1O X-Received: from wmbfl27.prod.google.com ([2002:a05:600c:b9b:b0:434:f1d0:7dc9]) (user=ardb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:1383:b0:439:9a5a:d3a5 with SMTP id 5b1f17b1804b1-439aeae186dmr20877285e9.1.1740146234049; Fri, 21 Feb 2025 05:57:14 -0800 (PST) Date: Fri, 21 Feb 2025 14:57:06 +0100 In-Reply-To: <20250221135704.431269-4-ardb+git@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250221135704.431269-4-ardb+git@google.com> X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 X-Developer-Signature: v=1; a=openpgp-sha256; l=1998; i=ardb@kernel.org; h=from:subject; bh=qMOouDoNVEK00y+HH+qNoH/b3RqloGuhSktNBenc3kE=; b=owGbwMvMwCFmkMcZplerG8N4Wi2JIX1Hm5Efe0ljepWmvlq70RRXld+/Zu53tny8Q0ONea/FX Ikomz8dpSwMYhwMsmKKLAKz/77beXqiVK3zLFmYOaxMIEMYuDgFYCJV1xgZWl/eP+v3+PupjU4H rLqeqC5s8mkTuideZRltsfrLtBoBPUaGM+phP2tYz7z1a63lEs068mz7/p3Vl2QeGOj/ZZC02rm YGwA= X-Mailer: git-send-email 2.48.1.601.g30ceb7b040-goog Message-ID: <20250221135704.431269-5-ardb+git@google.com> Subject: [PATCH v3 1/2] vmlinux.lds: Ensure that const vars with relocations are mapped R/O From: Ard Biesheuvel To: linux-kernel@vger.kernel.org Cc: x86@kernel.org, Huacai Chen , Ard Biesheuvel , Josh Poimboeuf , Peter Zijlstra , Tiezhu Yang , stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ard Biesheuvel In the kernel, there are architectures (x86, arm64) that perform boot-time relocation (for KASLR) without relying on PIE codegen. In this case, all const global objects are emitted into .rodata, including const objects with fields that will be fixed up by the boot-time relocation code. This implies that .rodata (and .text in some cases) need to be writable at boot, but they will usually be mapped read-only as soon as the boot completes. When using PIE codegen, the compiler will emit const global objects into .data.rel.ro rather than .rodata if the object contains fields that need such fixups at boot-time. This permits the linker to annotate such regions as requiring read-write access only at load time, but not at execution time (in user space), while keeping .rodata truly const (in user space, this is important for reducing the CoW footprint of dynamic executables). This distinction does not matter for the kernel, but it does imply that const data will end up in writable memory if the .data.rel.ro sections are not treated in a special way, as they will end up in the writable .data segment by default. So emit .data.rel.ro into the .rodata segment. Cc: Signed-off-by: Ard Biesheuvel --- include/asm-generic/vmlinux.lds.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinu= x.lds.h index 02a4adb4a999..0d5b186abee8 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -457,7 +457,7 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELL= ER_CLANG) . =3D ALIGN((align)); \ .rodata : AT(ADDR(.rodata) - LOAD_OFFSET) { \ __start_rodata =3D .; \ - *(.rodata) *(.rodata.*) \ + *(.rodata) *(.rodata.*) *(.data.rel.ro*) \ SCHED_DATA \ RO_AFTER_INIT_DATA /* Read only after init */ \ . =3D ALIGN(8); \ --=20 2.48.1.601.g30ceb7b040-goog From nobody Fri Dec 19 04:49:40 2025 Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A8EAD192B74 for ; Fri, 21 Feb 2025 13:57:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740146239; cv=none; b=jNX53oqloQSfeSoctihWFBVcHf5cA/9ply6kXjXzGXksLnKlhvzE84KdfMwOjxfo/CsZqZu51IrmJj2uio+6iQP9gjyqlucS1wY59C8aoDRT3GeFCzNmjefk33zPpYhAyYC+MamJlDF+OJ62RiNOwB8/1QRWqNJeWF4KBJ0Aom8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740146239; c=relaxed/simple; bh=a79Mmvb7KAIRH0fH5w9wctIAGHoCSn1TnROgyt4BGz8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=m8dw1od2hsO4jpHt35jfEybSLusSYOrUZFvxMioVBxHH/V3k4DpGwtN6wyEwwT9xL38VWbi5o5+zH5Q6KxozX1yWqPYWUPubZbngPd2SMY2bdhklyGW/HxJgf38uRF6wenRJkYgk9d3ulWrV0V182N+7L/6k+03CQk1URKqI1MQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--ardb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=viHjQw7b; arc=none smtp.client-ip=209.85.128.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--ardb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="viHjQw7b" Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-43941ad86d4so10769625e9.2 for ; Fri, 21 Feb 2025 05:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740146236; x=1740751036; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=nzZpqR+jh487eF8Ng36zvgLqP3+9BSLuVj6q4tRe9h0=; b=viHjQw7bNr5zr+bpmuyAZukH0lIXokQAzAsaTUGXkUOAvyCNhHQwwnoaSDDy9YDf+/ ZMUQvACgfNIB64e/1DOws6bc+8gSJJuQgTXEk5AkrKBqb01nUWmuyW6KRLjNlr5nUQOX PsDUuvn1+qWQVKWFFVbbCR14fQJz6ddjjdzDLA+r7jdj6jylZPcdYp/rxWfSQTcKth35 kvRt3XMBEXDFJ1MRhQZIvrqyO2ZwsHeEgj600aGKmiBy10mwczvmmIJRNoB4YvHXMPe2 Zq7p0rpyzzeKxI7n9BEEB6L9oIsWlNaIRMH1k8M7NOjCwAeXHgspGRWGRgd7L7G4v05X PeZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740146236; x=1740751036; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nzZpqR+jh487eF8Ng36zvgLqP3+9BSLuVj6q4tRe9h0=; b=Iyr7M05bFH0V//VbinFJLJeJ6Mfyw2QyO/3VU8ZoNmEbUOhGNgXBI/pzvCrXjFsYdJ 1B74yaBa9QF7TEhOuBTkAtlp3G9VLcobH5yccQdRANcfXYOYVH6Xkof1oeuZxPDrOgND V7dYoGMowVPWwlY2uoeGYHWS6YC7ivi5F5rMdsgYV3oo9qgeFfclZ75Fk7hDoBt0GSA1 igi8ueU89eGz9+2H9cQRefg8MLZloINLorrpvA3Fg07cpQOi5VtfXNuso9a4Ibnd/Pi/ J5VP/icsyta19Vyuiz/aZFUD9AsUxAiq9u7CYRtfPB4Za2+13zCrnZSUmlPAGwLD0jQN cjew== X-Gm-Message-State: AOJu0YyADmnQpLSn1FT6hvg+c5n9YItXi5HrTb44oz+e6JlmENkHpfP8 9GtB//9WI9umJPqJqdh8dTkhCFoTx6BHRxOaMGoQ9nsZ8j49x3B/ozeEnYg0YrLdY0Ue1SpUNLq Uq+IDAhZy4Ri2YItcqhe3BYl+cwmQRCdgg9M7wntkPoFyuPD6pE6l1HxdqGd+M6Pby135OylNV/ YUx4nZBFB0BDlkXUvSz3iznHFNxjGFaA== X-Google-Smtp-Source: AGHT+IGgf8XLXw/Ci0RSrUYzS5I2txYam9Si6B3hNT5owr59LtHbugsfNJ7/J6gIMtKHEm3CNmAAlPdj X-Received: from wmbay22.prod.google.com ([2002:a05:600c:1e16:b0:439:66ab:de64]) (user=ardb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:5106:b0:439:a25a:1686 with SMTP id 5b1f17b1804b1-439aebda0bbmr20908835e9.25.1740146236005; Fri, 21 Feb 2025 05:57:16 -0800 (PST) Date: Fri, 21 Feb 2025 14:57:07 +0100 In-Reply-To: <20250221135704.431269-4-ardb+git@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250221135704.431269-4-ardb+git@google.com> X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 X-Developer-Signature: v=1; a=openpgp-sha256; l=4143; i=ardb@kernel.org; h=from:subject; bh=FEOqxJKJWN1Zy4dD53yjp/vbwnfOa33qirxv86HFvWo=; b=owGbwMvMwCFmkMcZplerG8N4Wi2JIX1Hm/Hr+3xb9nD982AOq347O72p6diSG3mTds1dyvxmy u4bq10zO0pZGMQ4GGTFFFkEZv99t/P0RKla51myMHNYmUCGMHBxCsBE/rgw/NPw+du77bjnNqW7 Zr4cy7Y7XFWVEZ8zryshlPvz/hP3H4sxMqxZXn5V8avA7QuhjYLTrp71OmK8uOewHtuWNL6lc6/ aH2ICAA== X-Mailer: git-send-email 2.48.1.601.g30ceb7b040-goog Message-ID: <20250221135704.431269-6-ardb+git@google.com> Subject: [PATCH v3 2/2] objtool: Fix C jump table annotations for Clang From: Ard Biesheuvel To: linux-kernel@vger.kernel.org Cc: x86@kernel.org, Huacai Chen , Ard Biesheuvel , Josh Poimboeuf , Peter Zijlstra , Tiezhu Yang Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ard Biesheuvel A C jump table (such as the one used by the BPF interpreter) is a const global array of absolute code addresses, and this means that the actual values in the table may not be known until the kernel is booted (e.g., when using KASLR or when the kernel VA space is sized dynamically). When using PIE codegen, the compiler will default to placing such const global objects in .data.rel.ro (which is annotated as writable), rather than .rodata (which is annotated as read-only). As C jump tables are explicitly emitted into .rodata, this used to result in warnings for LoongArch builds (which uses PIE codegen for the entire kernel) like Warning: setting incorrect section attributes for .rodata..c_jump_table due to the fact that the explicitly specified .rodata section inherited the read-write annotation that the compiler uses for such objects when using PIE codegen. This warning was suppressed by explicitly adding the read-only annotation to the __attribute__((section(""))) string, by commit c5b1184decc8 ("compiler.h: specify correct attribute for .rodata..c_jump_= table") Unfortunately, this hack does not work on Clang's integrated assembler, which happily interprets the appended section type and permission specifiers as part of the section name, which therefore no longer matches the hard-coded pattern '.rodata..c_jump_table' that objtool expects, causing it to emit a warning kernel/bpf/core.o: warning: objtool: ___bpf_prog_run+0x20: sibling call f= rom callable instruction with modified stack frame Work around this, by emitting C jump tables into .data.rel.ro instead, which is treated as .rodata by the linker script for all builds, not just PIE based ones. Fixes: c5b1184decc8 ("compiler.h: specify correct attribute for .rodata..c_= jump_table") Tested-by: Tiezhu Yang # on LoongArch Signed-off-by: Ard Biesheuvel --- include/linux/compiler.h | 2 +- tools/objtool/check.c | 7 ++++--- tools/objtool/include/objtool/special.h | 2 +- 3 files changed, 6 insertions(+), 5 deletions(-) diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 200fd3c5bc70..155385754824 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -110,7 +110,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f,= int val, /* Unreachable code */ #ifdef CONFIG_OBJTOOL /* Annotate a C jump table to allow objtool to follow the code flow */ -#define __annotate_jump_table __section(".rodata..c_jump_table,\"a\",@prog= bits #") +#define __annotate_jump_table __section(".data.rel.ro.c_jump_table") #else /* !CONFIG_OBJTOOL */ #define __annotate_jump_table #endif /* CONFIG_OBJTOOL */ diff --git a/tools/objtool/check.c b/tools/objtool/check.c index be18a0489303..ce973d9d8e6d 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -2472,13 +2472,14 @@ static void mark_rodata(struct objtool_file *file) * * - .rodata: can contain GCC switch tables * - .rodata.: same, if -fdata-sections is being used - * - .rodata..c_jump_table: contains C annotated jump tables + * - .data.rel.ro.c_jump_table: contains C annotated jump tables * * .rodata.str1.* sections are ignored; they don't contain jump tables. */ for_each_sec(file, sec) { - if (!strncmp(sec->name, ".rodata", 7) && - !strstr(sec->name, ".str1.")) { + if ((!strncmp(sec->name, ".rodata", 7) && + !strstr(sec->name, ".str1.")) || + !strncmp(sec->name, ".data.rel.ro", 12)) { sec->rodata =3D true; found =3D true; } diff --git a/tools/objtool/include/objtool/special.h b/tools/objtool/includ= e/objtool/special.h index e7ee7ffccefd..e049679bb17b 100644 --- a/tools/objtool/include/objtool/special.h +++ b/tools/objtool/include/objtool/special.h @@ -10,7 +10,7 @@ #include #include =20 -#define C_JUMP_TABLE_SECTION ".rodata..c_jump_table" +#define C_JUMP_TABLE_SECTION ".data.rel.ro.c_jump_table" =20 struct special_alt { struct list_head list; --=20 2.48.1.601.g30ceb7b040-goog