From nobody Sat Nov 23 23:35:34 2024 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 0D8971E7C18; Fri, 8 Nov 2024 14:43:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731077041; cv=none; b=QfXnwWPlTzX+neeewFoeAi9ZpOZjgW5MsvIHybLETRhHXLEBlKOPg7wZMFs4PwgpnNje1VKswnZ3jWK9VOBhDbaJJ3lU/dGi/Ks0MN8gxvH6k7634yrhJwCpczGOdtOQP3CJtQ7/g3v+U+c6U7Nn2qIq0YD6hEZm8Rc/qOfpWnE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731077041; c=relaxed/simple; bh=Msy2iTqg/kJs7o9qo5sRgxktV1FRQQZ+nvGttmdZCUU=; h=Date:From:To:Subject:Cc:In-Reply-To:References:MIME-Version: Message-ID:Content-Type; b=YPnOp6ydBt+GaOGktxCRKSylCNSM3I4UUKdgohy1jZok6KQumY+WYcNvvLI/GchiUd/uFXbAfrx+4kz3qGpC1RiD5zRrG6hpxcwVJNT2XQqpH5rjJ10HBdyCJIjzvVv29dYj4YwB10yMkDiTQ3bATeqpUEMcQL9ft25XT9Mmk1U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=JrniFjOX; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=dz492jxr; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="JrniFjOX"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="dz492jxr" Date: Fri, 08 Nov 2024 14:43:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1731077032; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/BGiMtoR2EBPFO8SNcItLJUGQK5+uT/5Evo+zHp2Etw=; b=JrniFjOXD0uUcuScEdhu++rXNw8H1p+1Cy322N8+jdr1X3V1VGnlpVE9UZ049unqFhjViN 8Ik5q6gX8xAtqBwvU5IFuku1X+oJybSctlFHoRa+cX818Hp6Z5AFUbhfCAAUf+yATRvx+B tNHAsWEPk79PFoFkO1MPoHnA5dcahtnGUHIabvV1mBXt3Sj1bHd92/iAtiyQ69IX9h81D+ vdDAO71TS3Q730y2howW/JUiWp/CMGwcldiPuggVS47icvKTYeA3NHVR10bjg7gvXfqBs1 V7n/abUufvro0zY+Fdzj7jebrpfyRQar1A27+1UBeg1JvZ7ux74Vk1tDxekuuw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1731077032; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/BGiMtoR2EBPFO8SNcItLJUGQK5+uT/5Evo+zHp2Etw=; b=dz492jxrQIhdLY7oJBwBfo7whTmM2xYZu9tp3W7omQJLXIlgi0sTJ/22Co+kRfLZ9gerRU 7WuoyHbfsgS8PlCw== From: "tip-bot2 for Ard Biesheuvel" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/urgent] x86/stackprotector: Work around strict Clang TLS symbol requirements Cc: Ard Biesheuvel , Brian Gerst , "Borislav Petkov (AMD)" , Nathan Chancellor , stable@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20241105155801.1779119-2-brgerst@gmail.com> References: <20241105155801.1779119-2-brgerst@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <173107703088.32228.15812209341461853188.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Precedence: bulk Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 577c134d311b9b94598d7a0c86be1f431f823003 Gitweb: https://git.kernel.org/tip/577c134d311b9b94598d7a0c86be1f431= f823003 Author: Ard Biesheuvel AuthorDate: Tue, 05 Nov 2024 10:57:46 -05:00 Committer: Borislav Petkov (AMD) CommitterDate: Fri, 08 Nov 2024 13:16:00 +01:00 x86/stackprotector: Work around strict Clang TLS symbol requirements GCC and Clang both implement stack protector support based on Thread Local Storage (TLS) variables, and this is used in the kernel to implement per-ta= sk stack cookies, by copying a task's stack cookie into a per-CPU variable eve= ry time it is scheduled in. Both now also implement -mstack-protector-guard-symbol=3D, which permits th= e TLS variable to be specified directly. This is useful because it will allow to move away from using a fixed offset of 40 bytes into the per-CPU area on x86_64, which requires a lot of special handling in the per-CPU code and the runtime relocation code. However, while GCC is rather lax in its implementation of this command line option, Clang actually requires that the provided symbol name refers to a T= LS variable (i.e., one declared with __thread), although it also permits the variable to be undeclared entirely, in which case it will use an implicit declaration of the right type. The upshot of this is that Clang will emit the correct references to the st= ack cookie variable in most cases, e.g., 10d: 64 a1 00 00 00 00 mov %fs:0x0,%eax 10f: R_386_32 __stack_chk_guard However, if a non-TLS definition of the symbol in question is visible in the same compilation unit (which amounts to the whole of vmlinux if LTO is enabled), it will drop the per-CPU prefix and emit a load from a bogus address. Work around this by using a symbol name that never occurs in C code, and em= it it as an alias in the linker script. Fixes: 3fb0fdb3bbe7 ("x86/stackprotector/32: Make the canary into a regular= percpu variable") Signed-off-by: Ard Biesheuvel Signed-off-by: Brian Gerst Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Cc: stable@vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/1854 Link: https://lore.kernel.org/r/20241105155801.1779119-2-brgerst@gmail.com --- arch/x86/Makefile | 5 +++-- arch/x86/entry/entry.S | 16 ++++++++++++++++ arch/x86/include/asm/asm-prototypes.h | 3 +++ arch/x86/kernel/cpu/common.c | 2 ++ arch/x86/kernel/vmlinux.lds.S | 3 +++ 5 files changed, 27 insertions(+), 2 deletions(-) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index cd75e78..5b773b3 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -142,9 +142,10 @@ ifeq ($(CONFIG_X86_32),y) =20 ifeq ($(CONFIG_STACKPROTECTOR),y) ifeq ($(CONFIG_SMP),y) - KBUILD_CFLAGS +=3D -mstack-protector-guard-reg=3Dfs -mstack-protector-g= uard-symbol=3D__stack_chk_guard + KBUILD_CFLAGS +=3D -mstack-protector-guard-reg=3Dfs \ + -mstack-protector-guard-symbol=3D__ref_stack_= chk_guard else - KBUILD_CFLAGS +=3D -mstack-protector-guard=3Dglobal + KBUILD_CFLAGS +=3D -mstack-protector-guard=3Dglobal endif endif else diff --git a/arch/x86/entry/entry.S b/arch/x86/entry/entry.S index 324686b..b7ea3e8 100644 --- a/arch/x86/entry/entry.S +++ b/arch/x86/entry/entry.S @@ -51,3 +51,19 @@ EXPORT_SYMBOL_GPL(mds_verw_sel); .popsection =20 THUNK warn_thunk_thunk, __warn_thunk + +#ifndef CONFIG_X86_64 +/* + * Clang's implementation of TLS stack cookies requires the variable in + * question to be a TLS variable. If the variable happens to be defined as= an + * ordinary variable with external linkage in the same compilation unit (w= hich + * amounts to the whole of vmlinux with LTO enabled), Clang will drop the + * segment register prefix from the references, resulting in broken code. = Work + * around this by avoiding the symbol used in -mstack-protector-guard-symb= ol=3D + * entirely in the C code, and use an alias emitted by the linker script + * instead. + */ +#ifdef CONFIG_STACKPROTECTOR +EXPORT_SYMBOL(__ref_stack_chk_guard); +#endif +#endif diff --git a/arch/x86/include/asm/asm-prototypes.h b/arch/x86/include/asm/a= sm-prototypes.h index 25466c4..3674006 100644 --- a/arch/x86/include/asm/asm-prototypes.h +++ b/arch/x86/include/asm/asm-prototypes.h @@ -20,3 +20,6 @@ extern void cmpxchg8b_emu(void); #endif =20 +#if defined(__GENKSYMS__) && defined(CONFIG_STACKPROTECTOR) +extern unsigned long __ref_stack_chk_guard; +#endif diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index a5f221e..f43bb97 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -2089,8 +2089,10 @@ void syscall_init(void) =20 #ifdef CONFIG_STACKPROTECTOR DEFINE_PER_CPU(unsigned long, __stack_chk_guard); +#ifndef CONFIG_SMP EXPORT_PER_CPU_SYMBOL(__stack_chk_guard); #endif +#endif =20 #endif /* CONFIG_X86_64 */ =20 diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index b8c5741..feb8102 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -491,6 +491,9 @@ SECTIONS . =3D ASSERT((_end - LOAD_OFFSET <=3D KERNEL_IMAGE_SIZE), "kernel image bigger than KERNEL_IMAGE_SIZE"); =20 +/* needed for Clang - see arch/x86/entry/entry.S */ +PROVIDE(__ref_stack_chk_guard =3D __stack_chk_guard); + #ifdef CONFIG_X86_64 /* * Per-cpu symbols which need to be offset from __per_cpu_load