All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb+git@google.com>
To: linux-kernel@vger.kernel.org
Cc: Ard Biesheuvel <ardb@kernel.org>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	 Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Uros Bizjak <ubizjak@gmail.com>,  Dennis Zhou <dennis@kernel.org>,
	Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>,
	 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	 Vitaly Kuznetsov <vkuznets@redhat.com>,
	Juergen Gross <jgross@suse.com>,
	 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	 Masahiro Yamada <masahiroy@kernel.org>,
	Kees Cook <kees@kernel.org>,
	 Nathan Chancellor <nathan@kernel.org>,
	Keith Packard <keithp@keithp.com>,
	 Justin Stitt <justinstitt@google.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	 Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
	 Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	 Kan Liang <kan.liang@linux.intel.com>,
	linux-doc@vger.kernel.org,  linux-pm@vger.kernel.org,
	kvm@vger.kernel.org, xen-devel@lists.xenproject.org,
	 linux-efi@vger.kernel.org, linux-arch@vger.kernel.org,
	 linux-sparse@vger.kernel.org, linux-kbuild@vger.kernel.org,
	 linux-perf-users@vger.kernel.org,
	rust-for-linux@vger.kernel.org,  llvm@lists.linux.dev
Subject: [RFC PATCH 05/28] x86: Define the stack protector guard symbol explicitly
Date: Wed, 25 Sep 2024 17:01:05 +0200	[thread overview]
Message-ID: <20240925150059.3955569-35-ardb+git@google.com> (raw)
In-Reply-To: <20240925150059.3955569-30-ardb+git@google.com>

From: Ard Biesheuvel <ardb@kernel.org>

Specify the guard symbol for the stack cookie explicitly, rather than
positioning it exactly 40 bytes into the per-CPU area. Doing so removes
the need for the per-CPU region to be absolute rather than relative to
the placement of the per-CPU template region in the kernel image, and
this allows the special handling for absolute per-CPU symbols to be
removed entirely.

This is a worthwhile cleanup in itself, but it is also a prerequisite
for PIE codegen and PIE linking, which can replace our bespoke and
rather clunky runtime relocation handling.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 arch/x86/Makefile                     |  4 ++++
 arch/x86/include/asm/init.h           |  2 +-
 arch/x86/include/asm/processor.h      | 11 +++--------
 arch/x86/include/asm/stackprotector.h |  4 ----
 tools/perf/util/annotate.c            |  4 ++--
 5 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 6b3fe6e2aadd..b78b7623a4a9 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -193,6 +193,10 @@ else
         KBUILD_RUSTFLAGS += -Cno-redzone=y
         KBUILD_RUSTFLAGS += -Ccode-model=kernel
 
+        ifeq ($(CONFIG_STACKPROTECTOR),y)
+                KBUILD_CFLAGS += -mstack-protector-guard-symbol=fixed_percpu_data
+        endif
+
         # Don't emit relaxable GOTPCREL relocations
         KBUILD_AFLAGS_KERNEL += -Wa,-mrelax-relocations=no
         KBUILD_CFLAGS_KERNEL += -Wa,-mrelax-relocations=no
diff --git a/arch/x86/include/asm/init.h b/arch/x86/include/asm/init.h
index 14d72727d7ee..3ed0e8ec973f 100644
--- a/arch/x86/include/asm/init.h
+++ b/arch/x86/include/asm/init.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_INIT_H
 #define _ASM_X86_INIT_H
 
-#define __head	__section(".head.text")
+#define __head	__section(".head.text") __no_stack_protector
 
 struct x86_mapping_info {
 	void *(*alloc_pgt_page)(void *); /* allocate buf for page table */
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 4a686f0e5dbf..56bc36116814 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -402,14 +402,9 @@ struct irq_stack {
 #ifdef CONFIG_X86_64
 struct fixed_percpu_data {
 	/*
-	 * GCC hardcodes the stack canary as %gs:40.  Since the
-	 * irq_stack is the object at %gs:0, we reserve the bottom
-	 * 48 bytes of the irq stack for the canary.
-	 *
-	 * Once we are willing to require -mstack-protector-guard-symbol=
-	 * support for x86_64 stackprotector, we can get rid of this.
+	 * Since the irq_stack is the object at %gs:0, the bottom 8 bytes of
+	 * the irq stack are reserved for the canary.
 	 */
-	char		gs_base[40];
 	unsigned long	stack_canary;
 };
 
@@ -418,7 +413,7 @@ DECLARE_INIT_PER_CPU(fixed_percpu_data);
 
 static inline unsigned long cpu_kernelmode_gs_base(int cpu)
 {
-	return (unsigned long)per_cpu(fixed_percpu_data.gs_base, cpu);
+	return (unsigned long)&per_cpu(fixed_percpu_data, cpu);
 }
 
 extern asmlinkage void entry_SYSCALL32_ignore(void);
diff --git a/arch/x86/include/asm/stackprotector.h b/arch/x86/include/asm/stackprotector.h
index 00473a650f51..d1dcd22a0a4c 100644
--- a/arch/x86/include/asm/stackprotector.h
+++ b/arch/x86/include/asm/stackprotector.h
@@ -51,10 +51,6 @@ static __always_inline void boot_init_stack_canary(void)
 {
 	unsigned long canary = get_random_canary();
 
-#ifdef CONFIG_X86_64
-	BUILD_BUG_ON(offsetof(struct fixed_percpu_data, stack_canary) != 40);
-#endif
-
 	current->stack_canary = canary;
 #ifdef CONFIG_X86_64
 	this_cpu_write(fixed_percpu_data.stack_canary, canary);
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 37ce43c4eb8f..7ecfedf5edb9 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -2485,10 +2485,10 @@ static bool is_stack_operation(struct arch *arch, struct disasm_line *dl)
 
 static bool is_stack_canary(struct arch *arch, struct annotated_op_loc *loc)
 {
-	/* On x86_64, %gs:40 is used for stack canary */
+	/* On x86_64, %gs:0 is used for stack canary */
 	if (arch__is(arch, "x86")) {
 		if (loc->segment == INSN_SEG_X86_GS && loc->imm &&
-		    loc->offset == 40)
+		    loc->offset == 0)
 			return true;
 	}
 
-- 
2.46.0.792.g87dc391469-goog


  parent reply	other threads:[~2024-09-25 15:02 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-25 15:01 [RFC PATCH 00/28] x86: Rely on toolchain for relocatable code Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 01/28] x86/pvh: Call C code via the kernel virtual mapping Ard Biesheuvel
2024-09-25 21:12   ` Jason Andryuk
2024-09-25 15:01 ` [RFC PATCH 02/28] Documentation: Bump minimum GCC version to 8.1 Ard Biesheuvel
2024-09-25 15:58   ` Arnd Bergmann
2024-12-19 11:53     ` Mark Rutland
2024-12-19 12:02       ` Arnd Bergmann
2024-09-26 21:35   ` Miguel Ojeda
2024-09-27 16:22   ` Mark Rutland
2024-09-25 15:01 ` [RFC PATCH 03/28] x86/tools: Use mmap() to simplify relocs host tool Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 04/28] x86/boot: Permit GOTPCREL relocations for x86_64 builds Ard Biesheuvel
2024-10-01  5:33   ` Josh Poimboeuf
2024-10-01  6:56     ` Ard Biesheuvel
2024-09-25 15:01 ` Ard Biesheuvel [this message]
2024-09-25 15:53   ` [RFC PATCH 05/28] x86: Define the stack protector guard symbol explicitly Ian Rogers
2024-09-25 17:43     ` Ard Biesheuvel
2024-09-25 17:48       ` Ian Rogers
2024-09-25 18:32   ` Uros Bizjak
2024-09-28 13:41     ` Brian Gerst
2024-10-04 13:15       ` Ard Biesheuvel
2024-10-08 14:36         ` Brian Gerst
2024-10-04 10:01   ` Uros Bizjak
2024-09-25 15:01 ` [RFC PATCH 06/28] x86/percpu: Get rid of absolute per-CPU variable placement Ard Biesheuvel
2024-09-25 17:56   ` Christoph Lameter (Ampere)
2024-09-25 15:01 ` [RFC PATCH 07/28] scripts/kallsyms: Avoid 0x0 as the relative base Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 08/28] scripts/kallsyms: Remove support for absolute per-CPU variables Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 09/28] x86/tools: Remove special relocation handling for " Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 10/28] x86/xen: Avoid relocatable quantities in Xen ELF notes Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 11/28] x86/pvh: Avoid absolute symbol references in .head.text Ard Biesheuvel
2024-09-25 21:10   ` Jason Andryuk
2024-09-25 21:50     ` Ard Biesheuvel
2024-09-25 22:40       ` Jason Andryuk
2024-09-25 15:01 ` [RFC PATCH 12/28] x86/pm-trace: Use RIP-relative accesses for .tracedata Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 13/28] x86/kvm: Use RIP-relative addressing Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 14/28] x86/rethook: Use RIP-relative reference for return address Ard Biesheuvel
2024-09-25 16:39   ` Linus Torvalds
2024-09-25 16:45     ` Ard Biesheuvel
2024-09-25 16:51       ` Andrew Cooper
2024-09-26  6:42         ` Jan Beulich
2024-09-25 15:01 ` [RFC PATCH 15/28] x86/sync_core: Use RIP-relative addressing Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 16/28] x86/entry_64: " Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 17/28] x86/hibernate: Prefer RIP-relative accesses Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 18/28] x86/boot/64: Determine VA/PA offset before entering C code Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 19/28] x86/boot/64: Avoid intentional absolute symbol references in .head.text Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 20/28] x64/acpi: Use PIC-compatible references in wakeup_64.S Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 21/28] x86/head: Use PIC-compatible symbol references in startup code Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 22/28] asm-generic: Treat PIC .data.rel.ro sections as .rodata Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 23/28] tools/objtool: Mark generated sections as writable Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 24/28] tools/objtool: Treat indirect ftrace calls as direct calls Ard Biesheuvel
2024-10-01  7:18   ` Josh Poimboeuf
2024-10-01  7:39     ` Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 25/28] x86: Use PIE codegen for the core kernel Ard Biesheuvel
2024-09-25 21:09   ` Andi Kleen
2024-09-25 21:23     ` Ard Biesheuvel
2024-09-26  8:48       ` Andi Kleen
2024-09-26 10:07         ` Ard Biesheuvel
2024-10-01 21:13   ` H. Peter Anvin
2024-10-02 15:25     ` Ard Biesheuvel
2024-10-02 20:01       ` Linus Torvalds
2024-10-03 11:13         ` Ard Biesheuvel
2024-10-04 21:06           ` H. Peter Anvin
2024-10-05  8:31             ` Uros Bizjak
2024-10-05 23:36               ` H. Peter Anvin
2024-10-06  0:00                 ` Linus Torvalds
2024-10-06  8:06                   ` Uros Bizjak
2024-10-06  7:59                 ` Uros Bizjak
2024-10-06 18:00                   ` David Laight
2024-10-06 19:17                     ` Uros Bizjak
2024-10-06 19:38                       ` H. Peter Anvin
2024-09-25 15:01 ` [RFC PATCH 26/28] x86/boot: Implement support for ELF RELA/RELR relocations Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 27/28] x86/kernel: Switch to PIE linking for the core kernel Ard Biesheuvel
2024-09-25 18:54   ` Uros Bizjak
2024-09-25 19:14     ` Ard Biesheuvel
2024-09-25 19:39       ` Uros Bizjak
2024-09-25 20:01         ` Ard Biesheuvel
2024-09-25 20:22           ` Uros Bizjak
2024-09-25 20:24   ` Vegard Nossum
2024-09-26 13:38     ` Ard Biesheuvel
2024-09-25 15:01 ` [RFC PATCH 28/28] x86/tools: Drop x86_64 support from 'relocs' tool Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240925150059.3955569-35-ardb+git@google.com \
    --to=ardb+git@google.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=boris.ostrovsky@oracle.com \
    --cc=cl@linux.com \
    --cc=dennis@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=irogers@google.com \
    --cc=jgross@suse.com \
    --cc=jolsa@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=justinstitt@google.com \
    --cc=kan.liang@linux.intel.com \
    --cc=kees@kernel.org \
    --cc=keithp@keithp.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=luto@kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=namhyung@kernel.org \
    --cc=nathan@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=ubizjak@gmail.com \
    --cc=vkuznets@redhat.com \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.