From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97AA4C433EF for ; Thu, 10 Mar 2022 14:20:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239010AbiCJOVK (ORCPT ); Thu, 10 Mar 2022 09:21:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43462 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243519AbiCJOR6 (ORCPT ); Thu, 10 Mar 2022 09:17:58 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EAD07160FE4; Thu, 10 Mar 2022 06:14:09 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 90A41B82615; Thu, 10 Mar 2022 14:14:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 55FD1C340E8; Thu, 10 Mar 2022 14:14:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921646; bh=6g3HeBO2zRKzOSmJFIYDEBU/mGaghVue+fBkH7lFoHw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rrvD82SB8HO69FZn2ZMyEXwSO+phRLpKkPu0X5W76rSSaIbobb28b/gKYvYOTH3EQ TnWqNC3cwFdO/cRruzPpYAi2UR9f8cgi85D05dC94cSlRqxdzWh5EnNraBjVJS/okx OFJbr3FMXrdn3wN2FvP4AyswNfFRIA6/afQrdGpA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Zhenzhong Duan , Borislav Petkov , Daniel Borkmann , David Woodhouse , "H. Peter Anvin" , Ingo Molnar , Konrad Rzeszutek Wilk , Peter Zijlstra , Thomas Gleixner , Wang YanQing , dhaval.giani@oracle.com, srinivas.eeda@oracle.com, Ben Hutchings Subject: [PATCH 4.9 01/38] x86/speculation: Add RETPOLINE_AMD support to the inline asm CALL_NOSPEC variant Date: Thu, 10 Mar 2022 15:13:14 +0100 Message-Id: <20220310140808.180700666@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhenzhong Duan commit 0cbb76d6285794f30953bfa3ab831714b59dd700 upstream. ..so that they match their asm counterpart. Add the missing ANNOTATE_NOSPEC_ALTERNATIVE in CALL_NOSPEC, while at it. Signed-off-by: Zhenzhong Duan Signed-off-by: Borislav Petkov Cc: Daniel Borkmann Cc: David Woodhouse Cc: H. Peter Anvin Cc: Ingo Molnar Cc: Konrad Rzeszutek Wilk Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Wang YanQing Cc: dhaval.giani@oracle.com Cc: srinivas.eeda@oracle.com Link: http://lkml.kernel.org/r/c3975665-173e-4d70-8dee-06c926ac26ee@default Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/nospec-branch.h | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -172,11 +172,15 @@ */ # define CALL_NOSPEC \ ANNOTATE_NOSPEC_ALTERNATIVE \ - ALTERNATIVE( \ + ALTERNATIVE_2( \ ANNOTATE_RETPOLINE_SAFE \ "call *%[thunk_target]\n", \ "call __x86_indirect_thunk_%V[thunk_target]\n", \ - X86_FEATURE_RETPOLINE) + X86_FEATURE_RETPOLINE, \ + "lfence;\n" \ + ANNOTATE_RETPOLINE_SAFE \ + "call *%[thunk_target]\n", \ + X86_FEATURE_RETPOLINE_AMD) # define THUNK_TARGET(addr) [thunk_target] "r" (addr) =20 #elif defined(CONFIG_X86_32) && defined(CONFIG_RETPOLINE) @@ -186,7 +190,8 @@ * here, anyway. */ # define CALL_NOSPEC \ - ALTERNATIVE( \ + ANNOTATE_NOSPEC_ALTERNATIVE \ + ALTERNATIVE_2( \ ANNOTATE_RETPOLINE_SAFE \ "call *%[thunk_target]\n", \ " jmp 904f;\n" \ @@ -201,7 +206,11 @@ " ret;\n" \ " .align 16\n" \ "904: call 901b;\n", \ - X86_FEATURE_RETPOLINE) + X86_FEATURE_RETPOLINE, \ + "lfence;\n" \ + ANNOTATE_RETPOLINE_SAFE \ + "call *%[thunk_target]\n", \ + X86_FEATURE_RETPOLINE_AMD) =20 # define THUNK_TARGET(addr) [thunk_target] "rm" (addr) #else /* No retpoline for C / inline asm */ From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14DF8C433EF for ; Thu, 10 Mar 2022 14:23:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237948AbiCJOYk (ORCPT ); Thu, 10 Mar 2022 09:24:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243761AbiCJOSV (ORCPT ); Thu, 10 Mar 2022 09:18:21 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4CBD1662D7; Thu, 10 Mar 2022 06:14:41 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6A0E6B825F3; Thu, 10 Mar 2022 14:14:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A43D0C340E8; Thu, 10 Mar 2022 14:14:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921680; bh=9xSbW6RIMMhTdHAqKKPczN6O01gAoWr/nHWbJelAumw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HZ3G9PrEV+RwmnYjAIgtWy2EH9RfcWeEAhtJzmJEYng1DXWyB52/GAWva2ZHteE4X 410jeH12h2EX0iB+jooaeKGlB7sidUFRrX5Yh81xoN2UBjrEklnvPZrFvAH0ntywaP I1l5xAAAJyx1lxGlTMDGTy9hxWNC81OjGc4L5+ZI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Peter Zijlstra , Zhenzhong Duan , Thomas Gleixner , David Woodhouse , Borislav Petkov , Daniel Borkmann , "H. Peter Anvin" , Konrad Rzeszutek Wilk , Andy Lutomirski , Masahiro Yamada , Michal Marek , srinivas.eeda@oracle.com, Ben Hutchings Subject: [PATCH 4.9 02/38] x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support Date: Thu, 10 Mar 2022 15:13:15 +0100 Message-Id: <20220310140808.209912532@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhenzhong Duan commit 4cd24de3a0980bf3100c9dcb08ef65ca7c31af48 upstream. Since retpoline capable compilers are widely available, make CONFIG_RETPOLINE hard depend on the compiler capability. Break the build when CONFIG_RETPOLINE is enabled and the compiler does not support it. Emit an error message in that case: "arch/x86/Makefile:226: *** You are building kernel with non-retpoline compiler, please update your compiler.. Stop." [dwmw: Fail the build with non-retpoline compiler] Suggested-by: Peter Zijlstra Signed-off-by: Zhenzhong Duan Signed-off-by: Thomas Gleixner Cc: David Woodhouse Cc: Borislav Petkov Cc: Daniel Borkmann Cc: H. Peter Anvin Cc: Konrad Rzeszutek Wilk Cc: Andy Lutomirski Cc: Masahiro Yamada Cc: Michal Marek Cc: Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/cca0cb20-f9e2-4094-840b-fb0f8810cd34@default [bwh: Backported to 4.9: - Drop change to objtool options - Adjust context, indentation] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/Kconfig | 4 ---- arch/x86/Makefile | 5 +++-- arch/x86/include/asm/nospec-branch.h | 10 ++++++---- arch/x86/kernel/cpu/bugs.c | 2 +- 4 files changed, 10 insertions(+), 11 deletions(-) --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -418,10 +418,6 @@ config RETPOLINE branches. Requires a compiler with -mindirect-branch=3Dthunk-extern support for full protection. The kernel may run slower. =20 - Without compiler support, at least indirect branches in assembler - code are eliminated. Since this includes the syscall entry path, - it is not entirely pointless. - if X86_32 config X86_EXTENDED_PLATFORM bool "Support for extended (non-PC) x86 platforms" --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -221,9 +221,10 @@ ifdef CONFIG_RETPOLINE RETPOLINE_CFLAGS_CLANG :=3D -mretpoline-external-thunk =20 RETPOLINE_CFLAGS +=3D $(call cc-option,$(RETPOLINE_CFLAGS_GCC),$(call = cc-option,$(RETPOLINE_CFLAGS_CLANG))) - ifneq ($(RETPOLINE_CFLAGS),) - KBUILD_CFLAGS +=3D $(RETPOLINE_CFLAGS) -DRETPOLINE + ifeq ($(RETPOLINE_CFLAGS),) + $(error You are building kernel with non-retpoline compiler, please = update your compiler.) endif + KBUILD_CFLAGS +=3D $(RETPOLINE_CFLAGS) endif =20 archscripts: scripts_basic --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -164,11 +164,12 @@ _ASM_PTR " 999b\n\t" \ ".popsection\n\t" =20 -#if defined(CONFIG_X86_64) && defined(RETPOLINE) +#ifdef CONFIG_RETPOLINE +#ifdef CONFIG_X86_64 =20 /* - * Since the inline asm uses the %V modifier which is only in newer GCC, - * the 64-bit one is dependent on RETPOLINE not CONFIG_RETPOLINE. + * Inline asm uses the %V modifier which is only in newer GCC + * which is ensured when CONFIG_RETPOLINE is defined. */ # define CALL_NOSPEC \ ANNOTATE_NOSPEC_ALTERNATIVE \ @@ -183,7 +184,7 @@ X86_FEATURE_RETPOLINE_AMD) # define THUNK_TARGET(addr) [thunk_target] "r" (addr) =20 -#elif defined(CONFIG_X86_32) && defined(CONFIG_RETPOLINE) +#else /* CONFIG_X86_32 */ /* * For i386 we use the original ret-equivalent retpoline, because * otherwise we'll run out of registers. We don't care about CET @@ -213,6 +214,7 @@ X86_FEATURE_RETPOLINE_AMD) =20 # define THUNK_TARGET(addr) [thunk_target] "rm" (addr) +#endif #else /* No retpoline for C / inline asm */ # define CALL_NOSPEC "call *%[thunk_target]\n" # define THUNK_TARGET(addr) [thunk_target] "rm" (addr) --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -812,7 +812,7 @@ static void __init spec_v2_print_cond(co =20 static inline bool retp_compiler(void) { - return __is_defined(RETPOLINE); + return __is_defined(CONFIG_RETPOLINE); } =20 static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void) From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 663FAC4332F for ; Thu, 10 Mar 2022 14:20:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243267AbiCJOVz (ORCPT ); Thu, 10 Mar 2022 09:21:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243871AbiCJOS3 (ORCPT ); Thu, 10 Mar 2022 09:18:29 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D9EF51567A6; Thu, 10 Mar 2022 06:14:59 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B624161CAA; Thu, 10 Mar 2022 14:14:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97677C340F7; Thu, 10 Mar 2022 14:14:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921697; bh=HSc3wFtLjti/d4eRAAzuyhTWC1ahVbUMNGqKeSkzAyQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rSDp0HdA3WItM0hoeye+WNTCemyAG44Ka8h3yDd5c/5PwNyTJdFkFl/ylBUa4HKIK lAH6XtQoPykujpweOnknWxXpfAMGE+cSwl0YuKVECJE5+h6dP/m0dMa4xmz2a5hNg7 mybCEGnJw2H6I3o6OQoD6oCEyXwQzdMv8h3p4hgM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Peter Zijlstra , Zhenzhong Duan , Thomas Gleixner , David Woodhouse , Borislav Petkov , "H. Peter Anvin" , Konrad Rzeszutek Wilk , srinivas.eeda@oracle.com, Ben Hutchings Subject: [PATCH 4.9 03/38] x86/retpoline: Remove minimal retpoline support Date: Thu, 10 Mar 2022 15:13:16 +0100 Message-Id: <20220310140808.238974462@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhenzhong Duan commit ef014aae8f1cd2793e4e014bbb102bed53f852b7 upstream. Now that CONFIG_RETPOLINE hard depends on compiler support, there is no reason to keep the minimal retpoline support around which only provided basic protection in the assembly files. Suggested-by: Peter Zijlstra Signed-off-by: Zhenzhong Duan Signed-off-by: Thomas Gleixner Cc: David Woodhouse Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Konrad Rzeszutek Wilk Cc: Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/f06f0a89-5587-45db-8ed2-0a9d6638d5c0@default Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/nospec-branch.h | 2 -- arch/x86/kernel/cpu/bugs.c | 13 ++----------- 2 files changed, 2 insertions(+), 13 deletions(-) --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -223,8 +223,6 @@ /* The Spectre V2 mitigation variants */ enum spectre_v2_mitigation { SPECTRE_V2_NONE, - SPECTRE_V2_RETPOLINE_MINIMAL, - SPECTRE_V2_RETPOLINE_MINIMAL_AMD, SPECTRE_V2_RETPOLINE_GENERIC, SPECTRE_V2_RETPOLINE_AMD, SPECTRE_V2_IBRS_ENHANCED, --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -784,8 +784,6 @@ set_mode: =20 static const char * const spectre_v2_strings[] =3D { [SPECTRE_V2_NONE] =3D "Vulnerable", - [SPECTRE_V2_RETPOLINE_MINIMAL] =3D "Vulnerable: Minimal generic ASM retp= oline", - [SPECTRE_V2_RETPOLINE_MINIMAL_AMD] =3D "Vulnerable: Minimal AMD ASM retpo= line", [SPECTRE_V2_RETPOLINE_GENERIC] =3D "Mitigation: Full generic retpoline", [SPECTRE_V2_RETPOLINE_AMD] =3D "Mitigation: Full AMD retpoline", [SPECTRE_V2_IBRS_ENHANCED] =3D "Mitigation: Enhanced IBRS", @@ -810,11 +808,6 @@ static void __init spec_v2_print_cond(co pr_info("%s selected on command line.\n", reason); } =20 -static inline bool retp_compiler(void) -{ - return __is_defined(CONFIG_RETPOLINE); -} - static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void) { enum spectre_v2_mitigation_cmd cmd =3D SPECTRE_V2_CMD_AUTO; @@ -912,14 +905,12 @@ retpoline_auto: pr_err("Spectre mitigation: LFENCE not serializing, switching to generi= c retpoline\n"); goto retpoline_generic; } - mode =3D retp_compiler() ? SPECTRE_V2_RETPOLINE_AMD : - SPECTRE_V2_RETPOLINE_MINIMAL_AMD; + mode =3D SPECTRE_V2_RETPOLINE_AMD; setup_force_cpu_cap(X86_FEATURE_RETPOLINE_AMD); setup_force_cpu_cap(X86_FEATURE_RETPOLINE); } else { retpoline_generic: - mode =3D retp_compiler() ? SPECTRE_V2_RETPOLINE_GENERIC : - SPECTRE_V2_RETPOLINE_MINIMAL; + mode =3D SPECTRE_V2_RETPOLINE_GENERIC; setup_force_cpu_cap(X86_FEATURE_RETPOLINE); } From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42CFAC4332F for ; Thu, 10 Mar 2022 14:22:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243506AbiCJOW4 (ORCPT ); Thu, 10 Mar 2022 09:22:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244176AbiCJOS7 (ORCPT ); Thu, 10 Mar 2022 09:18:59 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1776B250C; Thu, 10 Mar 2022 06:15:38 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C7C6661C83; Thu, 10 Mar 2022 14:15:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8AA65C340E8; Thu, 10 Mar 2022 14:14:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921700; bh=kHVjv2SJpGjFdTi9OPF5CEl1kGKJ5JbSMwNIfb9X+VE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DCLC4glsDzq/lgn5/4PhIUVZ+fRUl1HyFE+1jl0170hcKpmlFdOAHYCbkYSW8Tj6g ItIhMJyPUW5qoaFvHODxiydpxkMy95MAqNmVdi2ujNYJG8xoeQ7ai2Ku1Br0DVJXHm ux3mK36Wxr4XgLl9AwZd3TBqybzAExkwnUhbnqUk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andi Kleen , Tim Chen , Randy Dunlap , Thomas Gleixner , Jonathan Corbet , Ben Hutchings Subject: [PATCH 4.9 04/38] Documentation: Add section about CPU vulnerabilities for Spectre Date: Thu, 10 Mar 2022 15:13:17 +0100 Message-Id: <20220310140808.268036691@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Tim Chen commit 6e88559470f581741bcd0f2794f9054814ac9740 upstream. Add documentation for Spectre vulnerability and the mitigation mechanisms: - Explain the problem and risks - Document the mitigation mechanisms - Document the command line controls - Document the sysfs files Co-developed-by: Andi Kleen Signed-off-by: Andi Kleen Co-developed-by: Tim Chen Signed-off-by: Tim Chen Reviewed-by: Randy Dunlap Reviewed-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet [bwh: Backported to 4.9: - Drop chnages in spec_ctrl.rst, which is a plain-text document here - Adjust filenames and references to spec_ctrl.rst] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- Documentation/hw-vuln/index.rst | 1=20 Documentation/hw-vuln/spectre.rst | 697 +++++++++++++++++++++++++++++++++= +++++ 2 files changed, 698 insertions(+) create mode 100644 Documentation/hw-vuln/spectre.rst --- a/Documentation/hw-vuln/index.rst +++ b/Documentation/hw-vuln/index.rst @@ -9,6 +9,7 @@ are configurable at compile, boot or run .. toctree:: :maxdepth: 1 =20 + spectre l1tf mds tsx_async_abort --- /dev/null +++ b/Documentation/hw-vuln/spectre.rst @@ -0,0 +1,697 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Spectre Side Channels +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Spectre is a class of side channel attacks that exploit branch prediction +and speculative execution on modern CPUs to read memory, possibly +bypassing access controls. Speculative execution side channel exploits +do not modify memory but attempt to infer privileged data in the memory. + +This document covers Spectre variant 1 and Spectre variant 2. + +Affected processors +------------------- + +Speculative execution side channel methods affect a wide range of modern +high performance processors, since most modern high speed processors +use branch prediction and speculative execution. + +The following CPUs are vulnerable: + + - Intel Core, Atom, Pentium, and Xeon processors + + - AMD Phenom, EPYC, and Zen processors + + - IBM POWER and zSeries processors + + - Higher end ARM processors + + - Apple CPUs + + - Higher end MIPS CPUs + + - Likely most other high performance CPUs. Contact your CPU vendor for= details. + +Whether a processor is affected or not can be read out from the Spectre +vulnerability files in sysfs. See :ref:`spectre_sys_info`. + +Related CVEs +------------ + +The following CVE entries describe Spectre variants: + + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D + CVE-2017-5753 Bounds check bypass Spectre variant 1 + CVE-2017-5715 Branch target injection Spectre variant 2 + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D + +Problem +------- + +CPUs use speculative operations to improve performance. That may leave +traces of memory accesses or computations in the processor's caches, +buffers, and branch predictors. Malicious software may be able to +influence the speculative execution paths, and then use the side effects +of the speculative execution in the CPUs' caches and buffers to infer +privileged data touched during the speculative execution. + +Spectre variant 1 attacks take advantage of speculative execution of +conditional branches, while Spectre variant 2 attacks use speculative +execution of indirect branches to leak privileged memory. +See :ref:`[1] ` :ref:`[5] ` :ref:`[7] ` +:ref:`[10] ` :ref:`[11] `. + +Spectre variant 1 (Bounds Check Bypass) +--------------------------------------- + +The bounds check bypass attack :ref:`[2] ` takes advantage +of speculative execution that bypasses conditional branch instructions +used for memory access bounds check (e.g. checking if the index of an +array results in memory access within a valid range). This results in +memory accesses to invalid memory (with out-of-bound index) that are +done speculatively before validation checks resolve. Such speculative +memory accesses can leave side effects, creating side channels which +leak information to the attacker. + +There are some extensions of Spectre variant 1 attacks for reading data +over the network, see :ref:`[12] `. However such attacks +are difficult, low bandwidth, fragile, and are considered low risk. + +Spectre variant 2 (Branch Target Injection) +------------------------------------------- + +The branch target injection attack takes advantage of speculative +execution of indirect branches :ref:`[3] `. The indirect +branch predictors inside the processor used to guess the target of +indirect branches can be influenced by an attacker, causing gadget code +to be speculatively executed, thus exposing sensitive data touched by +the victim. The side effects left in the CPU's caches during speculative +execution can be measured to infer data values. + +.. _poison_btb: + +In Spectre variant 2 attacks, the attacker can steer speculative indirect +branches in the victim to gadget code by poisoning the branch target +buffer of a CPU used for predicting indirect branch addresses. Such +poisoning could be done by indirect branching into existing code, +with the address offset of the indirect branch under the attacker's +control. Since the branch prediction on impacted hardware does not +fully disambiguate branch address and uses the offset for prediction, +this could cause privileged code's indirect branch to jump to a gadget +code with the same offset. + +The most useful gadgets take an attacker-controlled input parameter (such +as a register value) so that the memory read can be controlled. Gadgets +without input parameters might be possible, but the attacker would have +very little control over what memory can be read, reducing the risk of +the attack revealing useful data. + +One other variant 2 attack vector is for the attacker to poison the +return stack buffer (RSB) :ref:`[13] ` to cause speculative +subroutine return instruction execution to go to a gadget. An attacker's +imbalanced subroutine call instructions might "poison" entries in the +return stack buffer which are later consumed by a victim's subroutine +return instructions. This attack can be mitigated by flushing the return +stack buffer on context switch, or virtual machine (VM) exit. + +On systems with simultaneous multi-threading (SMT), attacks are possible +from the sibling thread, as level 1 cache and branch target buffer +(BTB) may be shared between hardware threads in a CPU core. A malicious +program running on the sibling thread may influence its peer's BTB to +steer its indirect branch speculations to gadget code, and measure the +speculative execution's side effects left in level 1 cache to infer the +victim's data. + +Attack scenarios +---------------- + +The following list of attack scenarios have been anticipated, but may +not cover all possible attack vectors. + +1. A user process attacking the kernel +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + The attacker passes a parameter to the kernel via a register or + via a known address in memory during a syscall. Such parameter may + be used later by the kernel as an index to an array or to derive + a pointer for a Spectre variant 1 attack. The index or pointer + is invalid, but bound checks are bypassed in the code branch taken + for speculative execution. This could cause privileged memory to be + accessed and leaked. + + For kernel code that has been identified where data pointers could + potentially be influenced for Spectre attacks, new "nospec" accessor + macros are used to prevent speculative loading of data. + + Spectre variant 2 attacker can :ref:`poison ` the branch + target buffer (BTB) before issuing syscall to launch an attack. + After entering the kernel, the kernel could use the poisoned branch + target buffer on indirect jump and jump to gadget code in speculative + execution. + + If an attacker tries to control the memory addresses leaked during + speculative execution, he would also need to pass a parameter to the + gadget, either through a register or a known address in memory. After + the gadget has executed, he can measure the side effect. + + The kernel can protect itself against consuming poisoned branch + target buffer entries by using return trampolines (also known as + "retpoline") :ref:`[3] ` :ref:`[9] ` for all + indirect branches. Return trampolines trap speculative execution paths + to prevent jumping to gadget code during speculative execution. + x86 CPUs with Enhanced Indirect Branch Restricted Speculation + (Enhanced IBRS) available in hardware should use the feature to + mitigate Spectre variant 2 instead of retpoline. Enhanced IBRS is + more efficient than retpoline. + + There may be gadget code in firmware which could be exploited with + Spectre variant 2 attack by a rogue user process. To mitigate such + attacks on x86, Indirect Branch Restricted Speculation (IBRS) feature + is turned on before the kernel invokes any firmware code. + +2. A user process attacking another user process +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + A malicious user process can try to attack another user process, + either via a context switch on the same hardware thread, or from the + sibling hyperthread sharing a physical processor core on simultaneous + multi-threading (SMT) system. + + Spectre variant 1 attacks generally require passing parameters + between the processes, which needs a data passing relationship, such + as remote procedure calls (RPC). Those parameters are used in gadget + code to derive invalid data pointers accessing privileged memory in + the attacked process. + + Spectre variant 2 attacks can be launched from a rogue process by + :ref:`poisoning ` the branch target buffer. This can + influence the indirect branch targets for a victim process that either + runs later on the same hardware thread, or running concurrently on + a sibling hardware thread sharing the same physical core. + + A user process can protect itself against Spectre variant 2 attacks + by using the prctl() syscall to disable indirect branch speculation + for itself. An administrator can also cordon off an unsafe process + from polluting the branch target buffer by disabling the process's + indirect branch speculation. This comes with a performance cost + from not using indirect branch speculation and clearing the branch + target buffer. When SMT is enabled on x86, for a process that has + indirect branch speculation disabled, Single Threaded Indirect Branch + Predictors (STIBP) :ref:`[4] ` are turned on to prevent the + sibling thread from controlling branch target buffer. In addition, + the Indirect Branch Prediction Barrier (IBPB) is issued to clear the + branch target buffer when context switching to and from such process. + + On x86, the return stack buffer is stuffed on context switch. + This prevents the branch target buffer from being used for branch + prediction when the return stack buffer underflows while switching to + a deeper call stack. Any poisoned entries in the return stack buffer + left by the previous process will also be cleared. + + User programs should use address space randomization to make attacks + more difficult (Set /proc/sys/kernel/randomize_va_space =3D 1 or 2). + +3. A virtualized guest attacking the host +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + The attack mechanism is similar to how user processes attack the + kernel. The kernel is entered via hyper-calls or other virtualization + exit paths. + + For Spectre variant 1 attacks, rogue guests can pass parameters + (e.g. in registers) via hyper-calls to derive invalid pointers to + speculate into privileged memory after entering the kernel. For places + where such kernel code has been identified, nospec accessor macros + are used to stop speculative memory access. + + For Spectre variant 2 attacks, rogue guests can :ref:`poison + ` the branch target buffer or return stack buffer, causing + the kernel to jump to gadget code in the speculative execution paths. + + To mitigate variant 2, the host kernel can use return trampolines + for indirect branches to bypass the poisoned branch target buffer, + and flushing the return stack buffer on VM exit. This prevents rogue + guests from affecting indirect branching in the host kernel. + + To protect host processes from rogue guests, host processes can have + indirect branch speculation disabled via prctl(). The branch target + buffer is cleared before context switching to such processes. + +4. A virtualized guest attacking other guest +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + A rogue guest may attack another guest to get data accessible by the + other guest. + + Spectre variant 1 attacks are possible if parameters can be passed + between guests. This may be done via mechanisms such as shared memory + or message passing. Such parameters could be used to derive data + pointers to privileged data in guest. The privileged data could be + accessed by gadget code in the victim's speculation paths. + + Spectre variant 2 attacks can be launched from a rogue guest by + :ref:`poisoning ` the branch target buffer or the return + stack buffer. Such poisoned entries could be used to influence + speculation execution paths in the victim guest. + + Linux kernel mitigates attacks to other guests running in the same + CPU hardware thread by flushing the return stack buffer on VM exit, + and clearing the branch target buffer before switching to a new guest. + + If SMT is used, Spectre variant 2 attacks from an untrusted guest + in the sibling hyperthread can be mitigated by the administrator, + by turning off the unsafe guest's indirect branch speculation via + prctl(). A guest can also protect itself by turning on microcode + based mitigations (such as IBPB or STIBP on x86) within the guest. + +.. _spectre_sys_info: + +Spectre system information +-------------------------- + +The Linux kernel provides a sysfs interface to enumerate the current +mitigation status of the system for Spectre: whether the system is +vulnerable, and which mitigations are active. + +The sysfs file showing Spectre variant 1 mitigation status is: + + /sys/devices/system/cpu/vulnerabilities/spectre_v1 + +The possible values in this file are: + + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + 'Mitigation: __user pointer sanitation' Protection in kernel on a case = by + case base with explicit pointer + sanitation. + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +However, the protections are put in place on a case by case basis, +and there is no guarantee that all possible attack vectors for Spectre +variant 1 are covered. + +The spectre_v2 kernel file reports if the kernel has been compiled with +retpoline mitigation or if the CPU has hardware mitigation, and if the +CPU has support for additional process-specific mitigation. + +This file also reports CPU features enabled by microcode to mitigate +attack between user processes: + +1. Indirect Branch Prediction Barrier (IBPB) to add additional + isolation between processes of different users. +2. Single Thread Indirect Branch Predictors (STIBP) to add additional + isolation between CPU threads running on the same core. + +These CPU features may impact performance when used and can be enabled +per process on a case-by-case base. + +The sysfs file showing Spectre variant 2 mitigation status is: + + /sys/devices/system/cpu/vulnerabilities/spectre_v2 + +The possible values in this file are: + + - Kernel status: + + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + 'Not affected' The processor is not vulnerable + 'Vulnerable' Vulnerable, no mitigation + 'Mitigation: Full generic retpoline' Software-focused mitigation + 'Mitigation: Full AMD retpoline' AMD-specific software mitigation + 'Mitigation: Enhanced IBRS' Hardware-focused mitigation + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + + - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS)= is + used to protect against Spectre variant 2 attacks when calling firmwar= e (x86 only). + + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + 'IBRS_FW' Protection against user program attacks when calling firmware + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + + - Indirect branch prediction barrier (IBPB) status for protection between + processes of different users. This feature can be controlled through + prctl() per process, or through kernel command line options. This is + an x86 only feature. For more details see below. + + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D + 'IBPB: disabled' IBPB unused + 'IBPB: always-on' Use IBPB on all tasks + 'IBPB: conditional' Use IBPB on SECCOMP or indirect branch restricted = tasks + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D + + - Single threaded indirect branch prediction (STIBP) status for protecti= on + between different hyper threads. This feature can be controlled through + prctl per process, or through kernel command line options. This is x86 + only feature. For more details see below. + + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D + 'STIBP: disabled' STIBP unused + 'STIBP: forced' Use STIBP on all tasks + 'STIBP: conditional' Use STIBP on SECCOMP or indirect branch restricted= tasks + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D + + - Return stack buffer (RSB) protection status: + + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D + 'RSB filling' Protection of RSB on context switch enabled + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D + +Full mitigation might require a microcode update from the CPU +vendor. When the necessary microcode is not available, the kernel will +report vulnerability. + +Turning on mitigation for Spectre variant 1 and Spectre variant 2 +----------------------------------------------------------------- + +1. Kernel mitigation +^^^^^^^^^^^^^^^^^^^^ + + For the Spectre variant 1, vulnerable kernel code (as determined + by code audit or scanning tools) is annotated on a case by case + basis to use nospec accessor macros for bounds clipping :ref:`[2] + ` to avoid any usable disclosure gadgets. However, it may + not cover all attack vectors for Spectre variant 1. + + For Spectre variant 2 mitigation, the compiler turns indirect calls or + jumps in the kernel into equivalent return trampolines (retpolines) + :ref:`[3] ` :ref:`[9] ` to go to the target + addresses. Speculative execution paths under retpolines are trapped + in an infinite loop to prevent any speculative execution jumping to + a gadget. + + To turn on retpoline mitigation on a vulnerable CPU, the kernel + needs to be compiled with a gcc compiler that supports the + -mindirect-branch=3Dthunk-extern -mindirect-branch-register options. + If the kernel is compiled with a Clang compiler, the compiler needs + to support -mretpoline-external-thunk option. The kernel config + CONFIG_RETPOLINE needs to be turned on, and the CPU needs to run with + the latest updated microcode. + + On Intel Skylake-era systems the mitigation covers most, but not all, + cases. See :ref:`[3] ` for more details. + + On CPUs with hardware mitigation for Spectre variant 2 (e.g. Enhanced + IBRS on x86), retpoline is automatically disabled at run time. + + The retpoline mitigation is turned on by default on vulnerable + CPUs. It can be forced on or off by the administrator + via the kernel command line and sysfs control files. See + :ref:`spectre_mitigation_control_command_line`. + + On x86, indirect branch restricted speculation is turned on by default + before invoking any firmware code to prevent Spectre variant 2 exploits + using the firmware. + + Using kernel address space randomization (CONFIG_RANDOMIZE_SLAB=3Dy + and CONFIG_SLAB_FREELIST_RANDOM=3Dy in the kernel configuration) makes + attacks on the kernel generally more difficult. + +2. User program mitigation +^^^^^^^^^^^^^^^^^^^^^^^^^^ + + User programs can mitigate Spectre variant 1 using LFENCE or "bounds + clipping". For more details see :ref:`[2] `. + + For Spectre variant 2 mitigation, individual user programs + can be compiled with return trampolines for indirect branches. + This protects them from consuming poisoned entries in the branch + target buffer left by malicious software. Alternatively, the + programs can disable their indirect branch speculation via prctl() + (See Documentation/spec_ctrl.txt). + On x86, this will turn on STIBP to guard against attacks from the + sibling thread when the user program is running, and use IBPB to + flush the branch target buffer when switching to/from the program. + + Restricting indirect branch speculation on a user program will + also prevent the program from launching a variant 2 attack + on x86. All sand-boxed SECCOMP programs have indirect branch + speculation restricted by default. Administrators can change + that behavior via the kernel command line and sysfs control files. + See :ref:`spectre_mitigation_control_command_line`. + + Programs that disable their indirect branch speculation will have + more overhead and run slower. + + User programs should use address space randomization + (/proc/sys/kernel/randomize_va_space =3D 1 or 2) to make attacks more + difficult. + +3. VM mitigation +^^^^^^^^^^^^^^^^ + + Within the kernel, Spectre variant 1 attacks from rogue guests are + mitigated on a case by case basis in VM exit paths. Vulnerable code + uses nospec accessor macros for "bounds clipping", to avoid any + usable disclosure gadgets. However, this may not cover all variant + 1 attack vectors. + + For Spectre variant 2 attacks from rogue guests to the kernel, the + Linux kernel uses retpoline or Enhanced IBRS to prevent consumption of + poisoned entries in branch target buffer left by rogue guests. It also + flushes the return stack buffer on every VM exit to prevent a return + stack buffer underflow so poisoned branch target buffer could be used, + or attacker guests leaving poisoned entries in the return stack buffer. + + To mitigate guest-to-guest attacks in the same CPU hardware thread, + the branch target buffer is sanitized by flushing before switching + to a new guest on a CPU. + + The above mitigations are turned on by default on vulnerable CPUs. + + To mitigate guest-to-guest attacks from sibling thread when SMT is + in use, an untrusted guest running in the sibling thread can have + its indirect branch speculation disabled by administrator via prctl(). + + The kernel also allows guests to use any microcode based mitigation + they choose to use (such as IBPB or STIBP on x86) to protect themselves. + +.. _spectre_mitigation_control_command_line: + +Mitigation control on the kernel command line +--------------------------------------------- + +Spectre variant 2 mitigation can be disabled or force enabled at the +kernel command line. + + nospectre_v2 + + [X86] Disable all mitigations for the Spectre variant 2 + (indirect branch prediction) vulnerability. System may + allow data leaks with this option, which is equivalent + to spectre_v2=3Doff. + + + spectre_v2=3D + + [X86] Control mitigation of Spectre variant 2 + (indirect branch speculation) vulnerability. + The default operation protects the kernel from + user space attacks. + + on + unconditionally enable, implies + spectre_v2_user=3Don + off + unconditionally disable, implies + spectre_v2_user=3Doff + auto + kernel detects whether your CPU model is + vulnerable + + Selecting 'on' will, and 'auto' may, choose a + mitigation method at run time according to the + CPU, the available microcode, the setting of the + CONFIG_RETPOLINE configuration option, and the + compiler with which the kernel was built. + + Selecting 'on' will also enable the mitigation + against user space to user space task attacks. + + Selecting 'off' will disable both the kernel and + the user space protections. + + Specific mitigations can also be selected manually: + + retpoline + replace indirect branches + retpoline,generic + google's original retpoline + retpoline,amd + AMD-specific minimal thunk + + Not specifying this option is equivalent to + spectre_v2=3Dauto. + +For user space mitigation: + + spectre_v2_user=3D + + [X86] Control mitigation of Spectre variant 2 + (indirect branch speculation) vulnerability between + user space tasks + + on + Unconditionally enable mitigations. Is + enforced by spectre_v2=3Don + + off + Unconditionally disable mitigations. Is + enforced by spectre_v2=3Doff + + prctl + Indirect branch speculation is enabled, + but mitigation can be enabled via prctl + per thread. The mitigation control state + is inherited on fork. + + prctl,ibpb + Like "prctl" above, but only STIBP is + controlled per thread. IBPB is issued + always when switching between different user + space processes. + + seccomp + Same as "prctl" above, but all seccomp + threads will enable the mitigation unless + they explicitly opt out. + + seccomp,ibpb + Like "seccomp" above, but only STIBP is + controlled per thread. IBPB is issued + always when switching between different + user space processes. + + auto + Kernel selects the mitigation depending on + the available CPU features and vulnerability. + + Default mitigation: + If CONFIG_SECCOMP=3Dy then "seccomp", otherwise "prctl" + + Not specifying this option is equivalent to + spectre_v2_user=3Dauto. + + In general the kernel by default selects + reasonable mitigations for the current CPU. To + disable Spectre variant 2 mitigations, boot with + spectre_v2=3Doff. Spectre variant 1 mitigations + cannot be disabled. + +Mitigation selection guide +-------------------------- + +1. Trusted userspace +^^^^^^^^^^^^^^^^^^^^ + + If all userspace applications are from trusted sources and do not + execute externally supplied untrusted code, then the mitigations can + be disabled. + +2. Protect sensitive programs +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + For security-sensitive programs that have secrets (e.g. crypto + keys), protection against Spectre variant 2 can be put in place by + disabling indirect branch speculation when the program is running + (See Documentation/spec_ctrl.txt). + +3. Sandbox untrusted programs +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + Untrusted programs that could be a source of attacks can be cordoned + off by disabling their indirect branch speculation when they are run + (See Documentation/spec_ctrl.txt). + This prevents untrusted programs from polluting the branch target + buffer. All programs running in SECCOMP sandboxes have indirect + branch speculation restricted by default. This behavior can be + changed via the kernel command line and sysfs control files. See + :ref:`spectre_mitigation_control_command_line`. + +3. High security mode +^^^^^^^^^^^^^^^^^^^^^ + + All Spectre variant 2 mitigations can be forced on + at boot time for all programs (See the "on" option in + :ref:`spectre_mitigation_control_command_line`). This will add + overhead as indirect branch speculations for all programs will be + restricted. + + On x86, branch target buffer will be flushed with IBPB when switching + to a new program. STIBP is left on all the time to protect programs + against variant 2 attacks originating from programs running on + sibling threads. + + Alternatively, STIBP can be used only when running programs + whose indirect branch speculation is explicitly disabled, + while IBPB is still used all the time when switching to a new + program to clear the branch target buffer (See "ibpb" option in + :ref:`spectre_mitigation_control_command_line`). This "ibpb" option + has less performance cost than the "on" option, which leaves STIBP + on all the time. + +References on Spectre +--------------------- + +Intel white papers: + +.. _spec_ref1: + +[1] `Intel analysis of speculative execution side channels `_. + +.. _spec_ref2: + +[2] `Bounds check bypass `_. + +.. _spec_ref3: + +[3] `Deep dive: Retpoline: A branch target injection mitigation `_. + +.. _spec_ref4: + +[4] `Deep Dive: Single Thread Indirect Branch Predictors `_. + +AMD white papers: + +.. _spec_ref5: + +[5] `AMD64 technology indirect branch control extension `_. + +.. _spec_ref6: + +[6] `Software techniques for managing speculation on AMD processors `_. + +ARM white papers: + +.. _spec_ref7: + +[7] `Cache speculation side-channels `_. + +.. _spec_ref8: + +[8] `Cache speculation issues update `_. + +Google white paper: + +.. _spec_ref9: + +[9] `Retpoline: a software construct for preventing branch-target-injectio= n `_. + +MIPS white paper: + +.. _spec_ref10: + +[10] `MIPS: response on speculative execution and side channel vulnerabili= ties `_. + +Academic papers: + +.. _spec_ref11: + +[11] `Spectre Attacks: Exploiting Speculative Execution `_. + +.. _spec_ref12: + +[12] `NetSpectre: Read Arbitrary Memory over Network `_. + +.. _spec_ref13: + +[13] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <= https://www.usenix.org/system/files/conference/woot18/woot18-paper-koruyeh.= pdf>`_. From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB3B6C433F5 for ; Thu, 10 Mar 2022 14:21:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243410AbiCJOWY (ORCPT ); Thu, 10 Mar 2022 09:22:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43492 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243921AbiCJOSb (ORCPT ); Thu, 10 Mar 2022 09:18:31 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F45416922A; Thu, 10 Mar 2022 06:15:06 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 45782B82676; Thu, 10 Mar 2022 14:15:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B0F60C36AE9; Thu, 10 Mar 2022 14:15:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921703; bh=ZrN6tfcrS9ZKAY3Hb7h4fgnYqO6MTLlatRmVtzqLU74=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lvdb8+yG2oy+R1gC1HSAa08Ih1mQIgTMWQFpmEXiVpXGGLcX17Yq38MnMB0bvL6vr 4Bywj/xUxyS77mLfLdQjVvmV0fGZbeShXtGxKd/kFpZzy4exRg8R1Mq4kRv4W5LTGM 9ZG8jkdsycPzdLUBWCk0/mHkPBFTf25/JIHd+Sck= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josh Poimboeuf , Thomas Gleixner , Ben Hutchings Subject: [PATCH 4.9 05/38] Documentation: Add swapgs description to the Spectre v1 documentation Date: Thu, 10 Mar 2022 15:13:18 +0100 Message-Id: <20220310140808.296536109@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Josh Poimboeuf commit 4c92057661a3412f547ede95715641d7ee16ddac upstream. Add documentation to the Spectre document about the new swapgs variant of Spectre v1. Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner [bwh: Backported to 4.9: adjust filename] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- Documentation/hw-vuln/spectre.rst | 88 +++++++++++++++++++++++++++++++++= +---- 1 file changed, 80 insertions(+), 8 deletions(-) --- a/Documentation/hw-vuln/spectre.rst +++ b/Documentation/hw-vuln/spectre.rst @@ -41,10 +41,11 @@ Related CVEs =20 The following CVE entries describe Spectre variants: =20 - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CVE-2017-5753 Bounds check bypass Spectre variant 1 CVE-2017-5715 Branch target injection Spectre variant 2 - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D + CVE-2019-1125 Spectre v1 swapgs Spectre variant 1 (swapgs) + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Problem ------- @@ -78,6 +79,13 @@ There are some extensions of Spectre var over the network, see :ref:`[12] `. However such attacks are difficult, low bandwidth, fragile, and are considered low risk. =20 +Note that, despite "Bounds Check Bypass" name, Spectre variant 1 is not +only about user-controlled array bounds checks. It can affect any +conditional checks. The kernel entry code interrupt, exception, and NMI +handlers all have conditional swapgs checks. Those may be problematic +in the context of Spectre v1, as kernel code can speculatively run with +a user GS. + Spectre variant 2 (Branch Target Injection) ------------------------------------------- =20 @@ -132,6 +140,9 @@ not cover all possible attack vectors. 1. A user process attacking the kernel ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ =20 +Spectre variant 1 +~~~~~~~~~~~~~~~~~ + The attacker passes a parameter to the kernel via a register or via a known address in memory during a syscall. Such parameter may be used later by the kernel as an index to an array or to derive @@ -144,7 +155,40 @@ not cover all possible attack vectors. potentially be influenced for Spectre attacks, new "nospec" accessor macros are used to prevent speculative loading of data. =20 - Spectre variant 2 attacker can :ref:`poison ` the branch +Spectre variant 1 (swapgs) +~~~~~~~~~~~~~~~~~~~~~~~~~~ + + An attacker can train the branch predictor to speculatively skip the + swapgs path for an interrupt or exception. If they initialize + the GS register to a user-space value, if the swapgs is speculatively + skipped, subsequent GS-related percpu accesses in the speculation + window will be done with the attacker-controlled GS value. This + could cause privileged memory to be accessed and leaked. + + For example: + + :: + + if (coming from user space) + swapgs + mov %gs:, %reg + mov (%reg), %reg1 + + When coming from user space, the CPU can speculatively skip the + swapgs, and then do a speculative percpu load using the user GS + value. So the user can speculatively force a read of any kernel + value. If a gadget exists which uses the percpu value as an address + in another load/store, then the contents of the kernel value may + become visible via an L1 side channel attack. + + A similar attack exists when coming from kernel space. The CPU can + speculatively do the swapgs, causing the user GS to get used for the + rest of the speculative window. + +Spectre variant 2 +~~~~~~~~~~~~~~~~~ + + A spectre variant 2 attacker can :ref:`poison ` the branch target buffer (BTB) before issuing syscall to launch an attack. After entering the kernel, the kernel could use the poisoned branch target buffer on indirect jump and jump to gadget code in speculative @@ -280,11 +324,18 @@ The sysfs file showing Spectre variant 1 =20 The possible values in this file are: =20 - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - 'Mitigation: __user pointer sanitation' Protection in kernel on a case = by - case base with explicit pointer - sanitation. - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + .. list-table:: + + * - 'Not affected' + - The processor is not vulnerable. + * - 'Vulnerable: __user pointer sanitization and usercopy barriers on= ly; no swapgs barriers' + - The swapgs protections are disabled; otherwise it has + protection in the kernel on a case by case base with explicit + pointer sanitation and usercopy LFENCE barriers. + * - 'Mitigation: usercopy/swapgs barriers and __user pointer sanitiza= tion' + - Protection in the kernel on a case by case base with explicit + pointer sanitation, usercopy LFENCE barriers, and swapgs LFENCE + barriers. =20 However, the protections are put in place on a case by case basis, and there is no guarantee that all possible attack vectors for Spectre @@ -366,12 +417,27 @@ Turning on mitigation for Spectre varian 1. Kernel mitigation ^^^^^^^^^^^^^^^^^^^^ =20 +Spectre variant 1 +~~~~~~~~~~~~~~~~~ + For the Spectre variant 1, vulnerable kernel code (as determined by code audit or scanning tools) is annotated on a case by case basis to use nospec accessor macros for bounds clipping :ref:`[2] ` to avoid any usable disclosure gadgets. However, it may not cover all attack vectors for Spectre variant 1. =20 + Copy-from-user code has an LFENCE barrier to prevent the access_ok() + check from being mis-speculated. The barrier is done by the + barrier_nospec() macro. + + For the swapgs variant of Spectre variant 1, LFENCE barriers are + added to interrupt, exception and NMI entry where needed. These + barriers are done by the FENCE_SWAPGS_KERNEL_ENTRY and + FENCE_SWAPGS_USER_ENTRY macros. + +Spectre variant 2 +~~~~~~~~~~~~~~~~~ + For Spectre variant 2 mitigation, the compiler turns indirect calls or jumps in the kernel into equivalent return trampolines (retpolines) :ref:`[3] ` :ref:`[9] ` to go to the target @@ -473,6 +539,12 @@ Mitigation control on the kernel command Spectre variant 2 mitigation can be disabled or force enabled at the kernel command line. =20 + nospectre_v1 + + [X86,PPC] Disable mitigations for Spectre Variant 1 + (bounds check bypass). With this option data leaks are + possible in the system. + nospectre_v2 =20 [X86] Disable all mitigations for the Spectre variant 2 From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AAD9C433F5 for ; Thu, 10 Mar 2022 14:21:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235686AbiCJOW3 (ORCPT ); Thu, 10 Mar 2022 09:22:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243937AbiCJOSc (ORCPT ); Thu, 10 Mar 2022 09:18:32 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ADF911693A8; Thu, 10 Mar 2022 06:15:08 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 3DAC2B82615; Thu, 10 Mar 2022 14:15:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3CDFC340EB; Thu, 10 Mar 2022 14:15:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921706; bh=/sdHsyS+hr3Sal/XN/Ek01i3/VYlSRYBbNSleu30DIE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FAipqprAzDAdDI9Kd1SwlQvA76DlBTCZrEaTEYncuhFZ+5f62nBI0w9u+l99sRpxL p/Tknzf6TLgO4bK8fewEVEZ3SDjLdQl6jBUnuNgC7NKo+6vTsqAh6y6MS/HWvvV+HB 7opWGX208YzNGny62nSfXkc7O9kDPxq0HgTx4/+0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lukas Bulwahn , Jonathan Corbet , Ben Hutchings Subject: [PATCH 4.9 06/38] Documentation: refer to config RANDOMIZE_BASE for kernel address-space randomization Date: Thu, 10 Mar 2022 15:13:19 +0100 Message-Id: <20220310140808.323981477@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Lukas Bulwahn commit 82ca67321f55a8d1da6ac3ed611da3c32818bb37 upstream. The config RANDOMIZE_SLAB does not exist, the authors probably intended to refer to the config RANDOMIZE_BASE, which provides kernel address-space randomization. They probably just confused SLAB with BASE (these two four-letter words coincidentally share three common letters), as they also point out the config SLAB_FREELIST_RANDOM as further randomization within the same sentence. Fix the reference of the config for kernel address-space randomization to the config that provides that. Fixes: 6e88559470f5 ("Documentation: Add section about CPU vulnerabilities = for Spectre") Signed-off-by: Lukas Bulwahn Link: https://lore.kernel.org/r/20211230171940.27558-1-lukas.bulwahn@gmail.= com Signed-off-by: Jonathan Corbet [bwh: Backported to 4.9: adjust filename] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- Documentation/hw-vuln/spectre.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/Documentation/hw-vuln/spectre.rst +++ b/Documentation/hw-vuln/spectre.rst @@ -468,7 +468,7 @@ Spectre variant 2 before invoking any firmware code to prevent Spectre variant 2 exploits using the firmware. =20 - Using kernel address space randomization (CONFIG_RANDOMIZE_SLAB=3Dy + Using kernel address space randomization (CONFIG_RANDOMIZE_BASE=3Dy and CONFIG_SLAB_FREELIST_RANDOM=3Dy in the kernel configuration) makes attacks on the kernel generally more difficult. From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A9DEC4167B for ; Thu, 10 Mar 2022 14:22:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243612AbiCJOXG (ORCPT ); Thu, 10 Mar 2022 09:23:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43302 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244271AbiCJOTG (ORCPT ); Thu, 10 Mar 2022 09:19:06 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1866E170D66; Thu, 10 Mar 2022 06:15:55 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9500461B5F; Thu, 10 Mar 2022 14:15:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 99C0BC340E8; Thu, 10 Mar 2022 14:15:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921710; bh=rzqdBWxT9hdyPrcwgYhGnVFeo744NwfXD7+4fOLZF78=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qdClAeoFpxL7Wc7ypcCS0jf5++IcptRHmNHVJsuaVrDBo4ZwhBLWlo6OEUjmAgbQF CPgN76WOIPzoUefBuVycU9kASEE4KPfw0GXmvi9OFRZgs2RuV/WbNdAvUR0tqCad9X PiiCdCft01gJ0tyAz+na0Bt8cNjknPcptDCqYUgA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Borislav Petkov , Anthony Steinhauser , Frank van der Linden , Ben Hutchings Subject: [PATCH 4.9 07/38] x86/speculation: Merge one test in spectre_v2_user_select_mitigation() Date: Thu, 10 Mar 2022 15:13:20 +0100 Message-Id: <20220310140808.351995623@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Borislav Petkov commit a5ce9f2bb665d1d2b31f139a02dbaa2dfbb62fa6 upstream. Merge the test whether the CPU supports STIBP into the test which determines whether STIBP is required. Thus try to simplify what is already an insane logic. Remove a superfluous newline in a comment, while at it. Signed-off-by: Borislav Petkov Cc: Anthony Steinhauser Link: https://lkml.kernel.org/r/20200615065806.GB14668@zn.tnic [fllinden@amazon.com: fixed contextual conflict (comment) for 4.19] Signed-off-by: Frank van der Linden Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/kernel/cpu/bugs.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -755,10 +755,12 @@ spectre_v2_user_select_mitigation(enum s } =20 /* - * If enhanced IBRS is enabled or SMT impossible, STIBP is not + * If no STIBP, enhanced IBRS is enabled or SMT impossible, STIBP is not * required. */ - if (!smt_possible || spectre_v2_enabled =3D=3D SPECTRE_V2_IBRS_ENHANCED) + if (!boot_cpu_has(X86_FEATURE_STIBP) || + !smt_possible || + spectre_v2_enabled =3D=3D SPECTRE_V2_IBRS_ENHANCED) return; =20 /* @@ -770,12 +772,6 @@ spectre_v2_user_select_mitigation(enum s boot_cpu_has(X86_FEATURE_AMD_STIBP_ALWAYS_ON)) mode =3D SPECTRE_V2_USER_STRICT_PREFERRED; =20 - /* - * If STIBP is not available, clear the STIBP mode. - */ - if (!boot_cpu_has(X86_FEATURE_STIBP)) - mode =3D SPECTRE_V2_USER_NONE; - spectre_v2_user_stibp =3D mode; =20 set_mode: @@ -1254,7 +1250,6 @@ static int ib_prctl_set(struct task_stru if (spectre_v2_user_ibpb =3D=3D SPECTRE_V2_USER_NONE && spectre_v2_user_stibp =3D=3D SPECTRE_V2_USER_NONE) return 0; - /* * With strict mode for both IBPB and STIBP, the instruction * code paths avoid checking this task flag and instead, From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8E45C433EF for ; Thu, 10 Mar 2022 14:24:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243527AbiCJOZg (ORCPT ); Thu, 10 Mar 2022 09:25:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243148AbiCJOV2 (ORCPT ); Thu, 10 Mar 2022 09:21:28 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BAAAAB250C; Thu, 10 Mar 2022 06:20:16 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4D1B0B8254A; Thu, 10 Mar 2022 14:15:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB4C5C340E8; Thu, 10 Mar 2022 14:15:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921713; bh=z8EgcjSQX1uiEBcBEJS+c1a5iDxnSom+wEXnmvXwijE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=r7IiA4BH9Zl6lcg4UKtmZlrDektV8GzwfWWXvbOnzk0bq9C0+J67oIpC5vKyw76uq AiJTGxRmdmXYag4Fb2OJbCrbBi4Z4OTLCjFyDnZ7OGsvjPNwOSr0QChhAiqz7hO5kK /YXuXR/KiQ1ASZsc2rHvXBQvUA3qUdGy+4hMEWhs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Peter Zijlstra (Intel)" , Borislav Petkov , Josh Poimboeuf , Alexei Starovoitov , Frank van der Linden , Ben Hutchings Subject: [PATCH 4.9 08/38] x86,bugs: Unconditionally allow spectre_v2=retpoline,amd Date: Thu, 10 Mar 2022 15:13:21 +0100 Message-Id: <20220310140808.380805567@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Peter Zijlstra commit f8a66d608a3e471e1202778c2a36cbdc96bae73b upstream. Currently Linux prevents usage of retpoline,amd on !AMD hardware, this is unfriendly and gets in the way of testing. Remove this restriction. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Borislav Petkov Acked-by: Josh Poimboeuf Tested-by: Alexei Starovoitov Link: https://lore.kernel.org/r/20211026120310.487348118@infradead.org [fllinden@amazon.com: backported to 4.19 (no Hygon in 4.19)] Signed-off-by: Frank van der Linden Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/kernel/cpu/bugs.c | 6 ------ 1 file changed, 6 deletions(-) --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -838,12 +838,6 @@ static enum spectre_v2_mitigation_cmd __ return SPECTRE_V2_CMD_AUTO; } =20 - if (cmd =3D=3D SPECTRE_V2_CMD_RETPOLINE_AMD && - boot_cpu_data.x86_vendor !=3D X86_VENDOR_AMD) { - pr_err("retpoline,amd selected but CPU is not AMD. Switching to AUTO sel= ect\n"); - return SPECTRE_V2_CMD_AUTO; - } - spec_v2_print_cond(mitigation_options[i].option, mitigation_options[i].secure); return cmd; From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D18FC433F5 for ; Thu, 10 Mar 2022 14:21:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243269AbiCJOWp (ORCPT ); Thu, 10 Mar 2022 09:22:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244017AbiCJOSj (ORCPT ); Thu, 10 Mar 2022 09:18:39 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B37D35E16E; Thu, 10 Mar 2022 06:15:20 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 872D261B36; Thu, 10 Mar 2022 14:15:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89852C340E8; Thu, 10 Mar 2022 14:15:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921716; bh=+mz+5eMq0OgWtr2QHJ4mrQIFSVCMwFfpozEZyqimju4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ymVcSSKf1GENkEPXUkreABpa8CKrjm7mlapMEqBWZr/mdoZiuL/VvQR7hmNUC2lll K4rPm47zfOoJYNWUTsEb9yzCCIopw7hB2RBoq0DAxLoULkr89krQ3/lKL7hHb+7k2B H66L5vJcLCTxKOc6YcFIo7axm6Qkh/YcS9jqJVsY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josh Poimboeuf , "Peter Zijlstra (Intel)" , Borislav Petkov , Thomas Gleixner , Frank van der Linden , Ben Hutchings Subject: [PATCH 4.9 09/38] x86/speculation: Rename RETPOLINE_AMD to RETPOLINE_LFENCE Date: Thu, 10 Mar 2022 15:13:22 +0100 Message-Id: <20220310140808.409210056@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "Peter Zijlstra (Intel)" commit d45476d9832409371537013ebdd8dc1a7781f97a upstream. The RETPOLINE_AMD name is unfortunate since it isn't necessarily AMD only, in fact Hygon also uses it. Furthermore it will likely be sufficient for some Intel processors. Therefore rename the thing to RETPOLINE_LFENCE to better describe what it is. Add the spectre_v2=3Dretpoline,lfence option as an alias to spectre_v2=3Dretpoline,amd to preserve existing setups. However, the output of /sys/devices/system/cpu/vulnerabilities/spectre_v2 will be changed. [ bp: Fix typos, massage. ] Co-developed-by: Josh Poimboeuf Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov Reviewed-by: Thomas Gleixner [fllinden@amazon.com: backported to 4.19] Signed-off-by: Frank van der Linden [bwh: Backported to 4.9: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/cpufeatures.h | 2 +- arch/x86/include/asm/nospec-branch.h | 12 ++++++------ arch/x86/kernel/cpu/bugs.c | 29 ++++++++++++++++++--------= --- tools/arch/x86/include/asm/cpufeatures.h | 2 +- 4 files changed, 26 insertions(+), 19 deletions(-) --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -195,7 +195,7 @@ #define X86_FEATURE_FENCE_SWAPGS_USER ( 7*32+10) /* "" LFENCE in user entr= y SWAPGS path */ #define X86_FEATURE_FENCE_SWAPGS_KERNEL ( 7*32+11) /* "" LFENCE in kernel = entry SWAPGS path */ #define X86_FEATURE_RETPOLINE ( 7*32+12) /* "" Generic Retpoline mitigatio= n for Spectre variant 2 */ -#define X86_FEATURE_RETPOLINE_AMD ( 7*32+13) /* "" AMD Retpoline mitigatio= n for Spectre variant 2 */ +#define X86_FEATURE_RETPOLINE_LFENCE ( 7*32+13) /* "" Use LFENCE for Spect= re variant 2 */ =20 #define X86_FEATURE_MSR_SPEC_CTRL ( 7*32+16) /* "" MSR SPEC_CTRL is implem= ented */ #define X86_FEATURE_SSBD ( 7*32+17) /* Speculative Store Bypass Disable */ --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -119,7 +119,7 @@ ANNOTATE_NOSPEC_ALTERNATIVE ALTERNATIVE_2 __stringify(ANNOTATE_RETPOLINE_SAFE; jmp *\reg), \ __stringify(RETPOLINE_JMP \reg), X86_FEATURE_RETPOLINE, \ - __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; jmp *\reg), X86_FEATURE_RET= POLINE_AMD + __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; jmp *\reg), X86_FEATURE_RET= POLINE_LFENCE #else jmp *\reg #endif @@ -130,7 +130,7 @@ ANNOTATE_NOSPEC_ALTERNATIVE ALTERNATIVE_2 __stringify(ANNOTATE_RETPOLINE_SAFE; call *\reg), \ __stringify(RETPOLINE_CALL \reg), X86_FEATURE_RETPOLINE,\ - __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; call *\reg), X86_FEATURE_RE= TPOLINE_AMD + __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; call *\reg), X86_FEATURE_RE= TPOLINE_LFENCE #else call *\reg #endif @@ -181,7 +181,7 @@ "lfence;\n" \ ANNOTATE_RETPOLINE_SAFE \ "call *%[thunk_target]\n", \ - X86_FEATURE_RETPOLINE_AMD) + X86_FEATURE_RETPOLINE_LFENCE) # define THUNK_TARGET(addr) [thunk_target] "r" (addr) =20 #else /* CONFIG_X86_32 */ @@ -211,7 +211,7 @@ "lfence;\n" \ ANNOTATE_RETPOLINE_SAFE \ "call *%[thunk_target]\n", \ - X86_FEATURE_RETPOLINE_AMD) + X86_FEATURE_RETPOLINE_LFENCE) =20 # define THUNK_TARGET(addr) [thunk_target] "rm" (addr) #endif @@ -223,8 +223,8 @@ /* The Spectre V2 mitigation variants */ enum spectre_v2_mitigation { SPECTRE_V2_NONE, - SPECTRE_V2_RETPOLINE_GENERIC, - SPECTRE_V2_RETPOLINE_AMD, + SPECTRE_V2_RETPOLINE, + SPECTRE_V2_LFENCE, SPECTRE_V2_IBRS_ENHANCED, }; =20 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -620,7 +620,7 @@ enum spectre_v2_mitigation_cmd { SPECTRE_V2_CMD_FORCE, SPECTRE_V2_CMD_RETPOLINE, SPECTRE_V2_CMD_RETPOLINE_GENERIC, - SPECTRE_V2_CMD_RETPOLINE_AMD, + SPECTRE_V2_CMD_RETPOLINE_LFENCE, }; =20 enum spectre_v2_user_cmd { @@ -780,8 +780,8 @@ set_mode: =20 static const char * const spectre_v2_strings[] =3D { [SPECTRE_V2_NONE] =3D "Vulnerable", - [SPECTRE_V2_RETPOLINE_GENERIC] =3D "Mitigation: Full generic retpoline", - [SPECTRE_V2_RETPOLINE_AMD] =3D "Mitigation: Full AMD retpoline", + [SPECTRE_V2_RETPOLINE] =3D "Mitigation: Retpolines", + [SPECTRE_V2_LFENCE] =3D "Mitigation: LFENCE", [SPECTRE_V2_IBRS_ENHANCED] =3D "Mitigation: Enhanced IBRS", }; =20 @@ -793,7 +793,8 @@ static const struct { { "off", SPECTRE_V2_CMD_NONE, false }, { "on", SPECTRE_V2_CMD_FORCE, true }, { "retpoline", SPECTRE_V2_CMD_RETPOLINE, false }, - { "retpoline,amd", SPECTRE_V2_CMD_RETPOLINE_AMD, false }, + { "retpoline,amd", SPECTRE_V2_CMD_RETPOLINE_LFENCE, false }, + { "retpoline,lfence", SPECTRE_V2_CMD_RETPOLINE_LFENCE, false }, { "retpoline,generic", SPECTRE_V2_CMD_RETPOLINE_GENERIC, false }, { "auto", SPECTRE_V2_CMD_AUTO, false }, }; @@ -831,13 +832,19 @@ static enum spectre_v2_mitigation_cmd __ } =20 if ((cmd =3D=3D SPECTRE_V2_CMD_RETPOLINE || - cmd =3D=3D SPECTRE_V2_CMD_RETPOLINE_AMD || + cmd =3D=3D SPECTRE_V2_CMD_RETPOLINE_LFENCE || cmd =3D=3D SPECTRE_V2_CMD_RETPOLINE_GENERIC) && !IS_ENABLED(CONFIG_RETPOLINE)) { pr_err("%s selected but not compiled in. Switching to AUTO select\n", mi= tigation_options[i].option); return SPECTRE_V2_CMD_AUTO; } =20 + if ((cmd =3D=3D SPECTRE_V2_CMD_RETPOLINE_LFENCE) && + !boot_cpu_has(X86_FEATURE_LFENCE_RDTSC)) { + pr_err("%s selected, but CPU doesn't have a serializing LFENCE. Switchin= g to AUTO select\n", mitigation_options[i].option); + return SPECTRE_V2_CMD_AUTO; + } + spec_v2_print_cond(mitigation_options[i].option, mitigation_options[i].secure); return cmd; @@ -872,9 +879,9 @@ static void __init spectre_v2_select_mit if (IS_ENABLED(CONFIG_RETPOLINE)) goto retpoline_auto; break; - case SPECTRE_V2_CMD_RETPOLINE_AMD: + case SPECTRE_V2_CMD_RETPOLINE_LFENCE: if (IS_ENABLED(CONFIG_RETPOLINE)) - goto retpoline_amd; + goto retpoline_lfence; break; case SPECTRE_V2_CMD_RETPOLINE_GENERIC: if (IS_ENABLED(CONFIG_RETPOLINE)) @@ -890,17 +897,17 @@ static void __init spectre_v2_select_mit =20 retpoline_auto: if (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_AMD) { - retpoline_amd: + retpoline_lfence: if (!boot_cpu_has(X86_FEATURE_LFENCE_RDTSC)) { pr_err("Spectre mitigation: LFENCE not serializing, switching to generi= c retpoline\n"); goto retpoline_generic; } - mode =3D SPECTRE_V2_RETPOLINE_AMD; - setup_force_cpu_cap(X86_FEATURE_RETPOLINE_AMD); + mode =3D SPECTRE_V2_LFENCE; + setup_force_cpu_cap(X86_FEATURE_RETPOLINE_LFENCE); setup_force_cpu_cap(X86_FEATURE_RETPOLINE); } else { retpoline_generic: - mode =3D SPECTRE_V2_RETPOLINE_GENERIC; + mode =3D SPECTRE_V2_RETPOLINE; setup_force_cpu_cap(X86_FEATURE_RETPOLINE); } =20 --- a/tools/arch/x86/include/asm/cpufeatures.h +++ b/tools/arch/x86/include/asm/cpufeatures.h @@ -194,7 +194,7 @@ #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface = */ =20 #define X86_FEATURE_RETPOLINE ( 7*32+12) /* "" Generic Retpoline mitigatio= n for Spectre variant 2 */ -#define X86_FEATURE_RETPOLINE_AMD ( 7*32+13) /* "" AMD Retpoline mitigatio= n for Spectre variant 2 */ +#define X86_FEATURE_RETPOLINE_LFENCE ( 7*32+13) /* "" Use LFENCEs for Spec= tre variant 2 */ =20 #define X86_FEATURE_MSR_SPEC_CTRL ( 7*32+16) /* "" MSR SPEC_CTRL is implem= ented */ #define X86_FEATURE_SSBD ( 7*32+17) /* Speculative Store Bypass Disable */ From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DB28C4167B for ; Thu, 10 Mar 2022 14:20:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243314AbiCJOVk (ORCPT ); Thu, 10 Mar 2022 09:21:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243707AbiCJOSS (ORCPT ); Thu, 10 Mar 2022 09:18:18 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8DA37163D52; Thu, 10 Mar 2022 06:14:35 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D4F4DB82670; Thu, 10 Mar 2022 14:14:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 47DD3C340E8; Thu, 10 Mar 2022 14:14:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921649; bh=MAWzUckPd/OtYxYEZm/KC/J38lZp28wkhlDepUsXuMU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Av3497NyNPiSOJWepp+PZJ4Gej7H8AGMPO86HOrxcscFV7dqaYEwY3bItqLcVXr9p tnAK3XjIPrY5vTedm9ELWSGtjbkKub7qXiMblsOM1M00/LLgGBJaJoqL7V2Rg1cMjv rpnUYHyK8f/qlZucAwOusr1rdE5oakVa64hsjsRc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josh Poimboeuf , "Peter Zijlstra (Intel)" , Borislav Petkov , Patrick Colp , Thomas Gleixner , Frank van der Linden , Ben Hutchings Subject: [PATCH 4.9 10/38] x86/speculation: Add eIBRS + Retpoline options Date: Thu, 10 Mar 2022 15:13:23 +0100 Message-Id: <20220310140808.437190794@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Peter Zijlstra commit 1e19da8522c81bf46b335f84137165741e0d82b7 upstream. Thanks to the chaps at VUsec it is now clear that eIBRS is not sufficient, therefore allow enabling of retpolines along with eIBRS. Add spectre_v2=3Deibrs, spectre_v2=3Deibrs,lfence and spectre_v2=3Deibrs,retpoline options to explicitly pick your preferred means of mitigation. Since there's new mitigations there's also user visible changes in /sys/devices/system/cpu/vulnerabilities/spectre_v2 to reflect these new mitigations. [ bp: Massage commit message, trim error messages, do more precise eIBRS mode checking. ] Co-developed-by: Josh Poimboeuf Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov Reviewed-by: Patrick Colp Reviewed-by: Thomas Gleixner [fllinden@amazon.com: backported to 4.19 (no Hygon)] Signed-off-by: Frank van der Linden Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/nospec-branch.h | 4 - arch/x86/kernel/cpu/bugs.c | 131 +++++++++++++++++++++++++-----= ----- 2 files changed, 98 insertions(+), 37 deletions(-) --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -225,7 +225,9 @@ enum spectre_v2_mitigation { SPECTRE_V2_NONE, SPECTRE_V2_RETPOLINE, SPECTRE_V2_LFENCE, - SPECTRE_V2_IBRS_ENHANCED, + SPECTRE_V2_EIBRS, + SPECTRE_V2_EIBRS_RETPOLINE, + SPECTRE_V2_EIBRS_LFENCE, }; =20 /* The indirect branch speculation control variants */ --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -621,6 +621,9 @@ enum spectre_v2_mitigation_cmd { SPECTRE_V2_CMD_RETPOLINE, SPECTRE_V2_CMD_RETPOLINE_GENERIC, SPECTRE_V2_CMD_RETPOLINE_LFENCE, + SPECTRE_V2_CMD_EIBRS, + SPECTRE_V2_CMD_EIBRS_RETPOLINE, + SPECTRE_V2_CMD_EIBRS_LFENCE, }; =20 enum spectre_v2_user_cmd { @@ -693,6 +696,13 @@ spectre_v2_parse_user_cmdline(enum spect return SPECTRE_V2_USER_CMD_AUTO; } =20 +static inline bool spectre_v2_in_eibrs_mode(enum spectre_v2_mitigation mod= e) +{ + return (mode =3D=3D SPECTRE_V2_EIBRS || + mode =3D=3D SPECTRE_V2_EIBRS_RETPOLINE || + mode =3D=3D SPECTRE_V2_EIBRS_LFENCE); +} + static void __init spectre_v2_user_select_mitigation(enum spectre_v2_mitigation_cmd v2_cmd) { @@ -760,7 +770,7 @@ spectre_v2_user_select_mitigation(enum s */ if (!boot_cpu_has(X86_FEATURE_STIBP) || !smt_possible || - spectre_v2_enabled =3D=3D SPECTRE_V2_IBRS_ENHANCED) + spectre_v2_in_eibrs_mode(spectre_v2_enabled)) return; =20 /* @@ -782,7 +792,9 @@ static const char * const spectre_v2_str [SPECTRE_V2_NONE] =3D "Vulnerable", [SPECTRE_V2_RETPOLINE] =3D "Mitigation: Retpolines", [SPECTRE_V2_LFENCE] =3D "Mitigation: LFENCE", - [SPECTRE_V2_IBRS_ENHANCED] =3D "Mitigation: Enhanced IBRS", + [SPECTRE_V2_EIBRS] =3D "Mitigation: Enhanced IBRS", + [SPECTRE_V2_EIBRS_LFENCE] =3D "Mitigation: Enhanced IBRS + LFENCE", + [SPECTRE_V2_EIBRS_RETPOLINE] =3D "Mitigation: Enhanced IBRS + Retpolines= ", }; =20 static const struct { @@ -796,6 +808,9 @@ static const struct { { "retpoline,amd", SPECTRE_V2_CMD_RETPOLINE_LFENCE, false }, { "retpoline,lfence", SPECTRE_V2_CMD_RETPOLINE_LFENCE, false }, { "retpoline,generic", SPECTRE_V2_CMD_RETPOLINE_GENERIC, false }, + { "eibrs", SPECTRE_V2_CMD_EIBRS, false }, + { "eibrs,lfence", SPECTRE_V2_CMD_EIBRS_LFENCE, false }, + { "eibrs,retpoline", SPECTRE_V2_CMD_EIBRS_RETPOLINE, false }, { "auto", SPECTRE_V2_CMD_AUTO, false }, }; =20 @@ -833,15 +848,29 @@ static enum spectre_v2_mitigation_cmd __ =20 if ((cmd =3D=3D SPECTRE_V2_CMD_RETPOLINE || cmd =3D=3D SPECTRE_V2_CMD_RETPOLINE_LFENCE || - cmd =3D=3D SPECTRE_V2_CMD_RETPOLINE_GENERIC) && + cmd =3D=3D SPECTRE_V2_CMD_RETPOLINE_GENERIC || + cmd =3D=3D SPECTRE_V2_CMD_EIBRS_LFENCE || + cmd =3D=3D SPECTRE_V2_CMD_EIBRS_RETPOLINE) && !IS_ENABLED(CONFIG_RETPOLINE)) { - pr_err("%s selected but not compiled in. Switching to AUTO select\n", mi= tigation_options[i].option); + pr_err("%s selected but not compiled in. Switching to AUTO select\n", + mitigation_options[i].option); + return SPECTRE_V2_CMD_AUTO; + } + + if ((cmd =3D=3D SPECTRE_V2_CMD_EIBRS || + cmd =3D=3D SPECTRE_V2_CMD_EIBRS_LFENCE || + cmd =3D=3D SPECTRE_V2_CMD_EIBRS_RETPOLINE) && + !boot_cpu_has(X86_FEATURE_IBRS_ENHANCED)) { + pr_err("%s selected but CPU doesn't have eIBRS. Switching to AUTO select= \n", + mitigation_options[i].option); return SPECTRE_V2_CMD_AUTO; } =20 - if ((cmd =3D=3D SPECTRE_V2_CMD_RETPOLINE_LFENCE) && + if ((cmd =3D=3D SPECTRE_V2_CMD_RETPOLINE_LFENCE || + cmd =3D=3D SPECTRE_V2_CMD_EIBRS_LFENCE) && !boot_cpu_has(X86_FEATURE_LFENCE_RDTSC)) { - pr_err("%s selected, but CPU doesn't have a serializing LFENCE. Switchin= g to AUTO select\n", mitigation_options[i].option); + pr_err("%s selected, but CPU doesn't have a serializing LFENCE. Switchin= g to AUTO select\n", + mitigation_options[i].option); return SPECTRE_V2_CMD_AUTO; } =20 @@ -850,6 +879,24 @@ static enum spectre_v2_mitigation_cmd __ return cmd; } =20 +static enum spectre_v2_mitigation __init spectre_v2_select_retpoline(void) +{ + if (!IS_ENABLED(CONFIG_RETPOLINE)) { + pr_err("Kernel not compiled with retpoline; no mitigation available!"); + return SPECTRE_V2_NONE; + } + + if (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_AMD) { + if (!boot_cpu_has(X86_FEATURE_LFENCE_RDTSC)) { + pr_err("LFENCE not serializing, switching to generic retpoline\n"); + return SPECTRE_V2_RETPOLINE; + } + return SPECTRE_V2_LFENCE; + } + + return SPECTRE_V2_RETPOLINE; +} + static void __init spectre_v2_select_mitigation(void) { enum spectre_v2_mitigation_cmd cmd =3D spectre_v2_parse_cmdline(); @@ -870,48 +917,60 @@ static void __init spectre_v2_select_mit case SPECTRE_V2_CMD_FORCE: case SPECTRE_V2_CMD_AUTO: if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED)) { - mode =3D SPECTRE_V2_IBRS_ENHANCED; - /* Force it so VMEXIT will restore correctly */ - x86_spec_ctrl_base |=3D SPEC_CTRL_IBRS; - wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base); - goto specv2_set_mode; + mode =3D SPECTRE_V2_EIBRS; + break; } - if (IS_ENABLED(CONFIG_RETPOLINE)) - goto retpoline_auto; + + mode =3D spectre_v2_select_retpoline(); break; + case SPECTRE_V2_CMD_RETPOLINE_LFENCE: - if (IS_ENABLED(CONFIG_RETPOLINE)) - goto retpoline_lfence; + mode =3D SPECTRE_V2_LFENCE; break; + case SPECTRE_V2_CMD_RETPOLINE_GENERIC: - if (IS_ENABLED(CONFIG_RETPOLINE)) - goto retpoline_generic; + mode =3D SPECTRE_V2_RETPOLINE; break; + case SPECTRE_V2_CMD_RETPOLINE: - if (IS_ENABLED(CONFIG_RETPOLINE)) - goto retpoline_auto; + mode =3D spectre_v2_select_retpoline(); + break; + + case SPECTRE_V2_CMD_EIBRS: + mode =3D SPECTRE_V2_EIBRS; + break; + + case SPECTRE_V2_CMD_EIBRS_LFENCE: + mode =3D SPECTRE_V2_EIBRS_LFENCE; + break; + + case SPECTRE_V2_CMD_EIBRS_RETPOLINE: + mode =3D SPECTRE_V2_EIBRS_RETPOLINE; break; } - pr_err("Spectre mitigation: kernel not compiled with retpoline; no mitiga= tion available!"); - return; =20 -retpoline_auto: - if (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_AMD) { - retpoline_lfence: - if (!boot_cpu_has(X86_FEATURE_LFENCE_RDTSC)) { - pr_err("Spectre mitigation: LFENCE not serializing, switching to generi= c retpoline\n"); - goto retpoline_generic; - } - mode =3D SPECTRE_V2_LFENCE; + if (spectre_v2_in_eibrs_mode(mode)) { + /* Force it so VMEXIT will restore correctly */ + x86_spec_ctrl_base |=3D SPEC_CTRL_IBRS; + wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base); + } + + switch (mode) { + case SPECTRE_V2_NONE: + case SPECTRE_V2_EIBRS: + break; + + case SPECTRE_V2_LFENCE: + case SPECTRE_V2_EIBRS_LFENCE: setup_force_cpu_cap(X86_FEATURE_RETPOLINE_LFENCE); + /* fallthrough */ + + case SPECTRE_V2_RETPOLINE: + case SPECTRE_V2_EIBRS_RETPOLINE: setup_force_cpu_cap(X86_FEATURE_RETPOLINE); - } else { - retpoline_generic: - mode =3D SPECTRE_V2_RETPOLINE; - setup_force_cpu_cap(X86_FEATURE_RETPOLINE); + break; } =20 -specv2_set_mode: spectre_v2_enabled =3D mode; pr_info("%s\n", spectre_v2_strings[mode]); =20 @@ -937,7 +996,7 @@ specv2_set_mode: * the CPU supports Enhanced IBRS, kernel might un-intentionally not * enable IBRS around firmware calls. */ - if (boot_cpu_has(X86_FEATURE_IBRS) && mode !=3D SPECTRE_V2_IBRS_ENHANCED)= { + if (boot_cpu_has(X86_FEATURE_IBRS) && !spectre_v2_in_eibrs_mode(mode)) { setup_force_cpu_cap(X86_FEATURE_USE_IBRS_FW); pr_info("Enabling Restricted Speculation for firmware calls\n"); } @@ -1597,7 +1656,7 @@ static ssize_t tsx_async_abort_show_stat =20 static char *stibp_state(void) { - if (spectre_v2_enabled =3D=3D SPECTRE_V2_IBRS_ENHANCED) + if (spectre_v2_in_eibrs_mode(spectre_v2_enabled)) return ""; =20 switch (spectre_v2_user_stibp) { From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 293CBC433FE for ; Thu, 10 Mar 2022 14:20:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243034AbiCJOV0 (ORCPT ); Thu, 10 Mar 2022 09:21:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243708AbiCJOSS (ORCPT ); Thu, 10 Mar 2022 09:18:18 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4BFA163D6F; Thu, 10 Mar 2022 06:14:35 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 13F56B825A7; Thu, 10 Mar 2022 14:14:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 505D5C340E8; Thu, 10 Mar 2022 14:14:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921652; bh=gzER/rtF+lYiIgmsa+QygKlUJbf9PTMWtZtRvs2hWTM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Wp8CDyr84IXSAifxQgRapygi6+yBBfV4CovNZeVwykgISAPTmNeKllgUwLwhFNqcd H6cKSbHlI0OGrUgQj3sLy6RRdqclrwWsaDBm/QPk+YKE9670tNAGrdpyD/KWw+4AD0 oIhgm3Bj9HVePkNY/iP3UkcBsu/RDiaubTxlKsuQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Peter Zijlstra (Intel)" , Borislav Petkov , Thomas Gleixner , Frank van der Linden , Ben Hutchings Subject: [PATCH 4.9 11/38] Documentation/hw-vuln: Update spectre doc Date: Thu, 10 Mar 2022 15:13:24 +0100 Message-Id: <20220310140808.466551509@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Peter Zijlstra commit 5ad3eb1132453b9795ce5fd4572b1c18b292cca9 upstream. Update the doc with the new fun. [ bp: Massage commit message. ] Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov Reviewed-by: Thomas Gleixner [fllinden@amazon.com: backported to 4.19] Signed-off-by: Frank van der Linden [bwh: Backported to 4.9: adjust filenames] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- Documentation/hw-vuln/spectre.rst | 42 ++++++++++++++++++++++++-------= ----- Documentation/kernel-parameters.txt | 8 +++++- 2 files changed, 35 insertions(+), 15 deletions(-) --- a/Documentation/hw-vuln/spectre.rst +++ b/Documentation/hw-vuln/spectre.rst @@ -131,6 +131,19 @@ steer its indirect branch speculations t speculative execution's side effects left in level 1 cache to infer the victim's data. =20 +Yet another variant 2 attack vector is for the attacker to poison the +Branch History Buffer (BHB) to speculatively steer an indirect branch +to a specific Branch Target Buffer (BTB) entry, even if the entry isn't +associated with the source address of the indirect branch. Specifically, +the BHB might be shared across privilege levels even in the presence of +Enhanced IBRS. + +Currently the only known real-world BHB attack vector is via +unprivileged eBPF. Therefore, it's highly recommended to not enable +unprivileged eBPF, especially when eIBRS is used (without retpolines). +For a full mitigation against BHB attacks, it's recommended to use +retpolines (or eIBRS combined with retpolines). + Attack scenarios ---------------- =20 @@ -364,13 +377,15 @@ The possible values in this file are: =20 - Kernel status: =20 - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - 'Not affected' The processor is not vulnerable - 'Vulnerable' Vulnerable, no mitigation - 'Mitigation: Full generic retpoline' Software-focused mitigation - 'Mitigation: Full AMD retpoline' AMD-specific software mitigation - 'Mitigation: Enhanced IBRS' Hardware-focused mitigation - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + 'Not affected' The processor is not vulnerable + 'Mitigation: None' Vulnerable, no mitigation + 'Mitigation: Retpolines' Use Retpoline thunks + 'Mitigation: LFENCE' Use LFENCE instructions + 'Mitigation: Enhanced IBRS' Hardware-focused mitigation + 'Mitigation: Enhanced IBRS + Retpolines' Hardware-focused + Retpolines + 'Mitigation: Enhanced IBRS + LFENCE' Hardware-focused + LFENCE + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS)= is used to protect against Spectre variant 2 attacks when calling firmwar= e (x86 only). @@ -584,12 +599,13 @@ kernel command line. =20 Specific mitigations can also be selected manually: =20 - retpoline - replace indirect branches - retpoline,generic - google's original retpoline - retpoline,amd - AMD-specific minimal thunk + retpoline auto pick between generic,lfence + retpoline,generic Retpolines + retpoline,lfence LFENCE; indirect branch + retpoline,amd alias for retpoline,lfence + eibrs enhanced IBRS + eibrs,retpoline enhanced IBRS + Retpolines + eibrs,lfence enhanced IBRS + LFENCE =20 Not specifying this option is equivalent to spectre_v2=3Dauto. --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -4174,8 +4174,12 @@ bytes respectively. Such letter suffixes Specific mitigations can also be selected manually: =20 retpoline - replace indirect branches - retpoline,generic - google's original retpoline - retpoline,amd - AMD-specific minimal thunk + retpoline,generic - Retpolines + retpoline,lfence - LFENCE; indirect branch + retpoline,amd - alias for retpoline,lfence + eibrs - enhanced IBRS + eibrs,retpoline - enhanced IBRS + Retpolines + eibrs,lfence - enhanced IBRS + LFENCE =20 Not specifying this option is equivalent to spectre_v2=3Dauto. From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6211C433F5 for ; Thu, 10 Mar 2022 14:23:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243627AbiCJOYg (ORCPT ); Thu, 10 Mar 2022 09:24:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243725AbiCJOSU (ORCPT ); Thu, 10 Mar 2022 09:18:20 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0341164D28; Thu, 10 Mar 2022 06:14:37 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 71AAE61B36; Thu, 10 Mar 2022 14:14:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F746C340E8; Thu, 10 Mar 2022 14:14:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921655; bh=B8Kqgr1X+xDFQnu3Mxsih+Dcynf9OwVEriW613XzwTI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TGPao9fSUwUorJ3+XYRpU+iNpnRSJGM2Ck1+k41TrWce+Dt/NNO8wvv7taHYiEwWw RWD3FPQsReosXVR5hYRgO+PG3KamFDKLBTwexaSH3ICAszxI4eNKB8TYxe8kCk2QdU fk+bmoGhjiJFRxWOgIFkQ39TNkzpSPx4Szu76Ub0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josh Poimboeuf , Borislav Petkov , Thomas Gleixner , Frank van der Linden , Ben Hutchings Subject: [PATCH 4.9 12/38] x86/speculation: Include unprivileged eBPF status in Spectre v2 mitigation reporting Date: Thu, 10 Mar 2022 15:13:25 +0100 Message-Id: <20220310140808.495542009@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Josh Poimboeuf commit 44a3918c8245ab10c6c9719dd12e7a8d291980d8 upstream. With unprivileged eBPF enabled, eIBRS (without retpoline) is vulnerable to Spectre v2 BHB-based attacks. When both are enabled, print a warning message and report it in the 'spectre_v2' sysfs vulnerabilities file. Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov Reviewed-by: Thomas Gleixner [fllinden@amazon.com: backported to 4.19] Signed-off-by: Frank van der Linden [bwh: Backported to 4.9: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/kernel/cpu/bugs.c | 35 +++++++++++++++++++++++++++++------ include/linux/bpf.h | 11 +++++++++++ kernel/sysctl.c | 8 ++++++++ 3 files changed, 48 insertions(+), 6 deletions(-) --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -30,6 +30,7 @@ #include #include #include +#include =20 #include "cpu.h" =20 @@ -606,6 +607,16 @@ static inline const char *spectre_v2_mod static inline const char *spectre_v2_module_string(void) { return ""; } #endif =20 +#define SPECTRE_V2_EIBRS_EBPF_MSG "WARNING: Unprivileged eBPF is enabled w= ith eIBRS on, data leaks possible via Spectre v2 BHB attacks!\n" + +#ifdef CONFIG_BPF_SYSCALL +void unpriv_ebpf_notify(int new_state) +{ + if (spectre_v2_enabled =3D=3D SPECTRE_V2_EIBRS && !new_state) + pr_err(SPECTRE_V2_EIBRS_EBPF_MSG); +} +#endif + static inline bool match_option(const char *arg, int arglen, const char *o= pt) { int len =3D strlen(opt); @@ -949,6 +960,9 @@ static void __init spectre_v2_select_mit break; } =20 + if (mode =3D=3D SPECTRE_V2_EIBRS && unprivileged_ebpf_enabled()) + pr_err(SPECTRE_V2_EIBRS_EBPF_MSG); + if (spectre_v2_in_eibrs_mode(mode)) { /* Force it so VMEXIT will restore correctly */ x86_spec_ctrl_base |=3D SPEC_CTRL_IBRS; @@ -1686,6 +1700,20 @@ static char *ibpb_state(void) return ""; } =20 +static ssize_t spectre_v2_show_state(char *buf) +{ + if (spectre_v2_enabled =3D=3D SPECTRE_V2_EIBRS && unprivileged_ebpf_enabl= ed()) + return sprintf(buf, "Vulnerable: Unprivileged eBPF enabled\n"); + + return sprintf(buf, "%s%s%s%s%s%s\n", + spectre_v2_strings[spectre_v2_enabled], + ibpb_state(), + boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ", IBRS_FW" : "", + stibp_state(), + boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? ", RSB filling" : "", + spectre_v2_module_string()); +} + static ssize_t srbds_show_state(char *buf) { return sprintf(buf, "%s\n", srbds_strings[srbds_mitigation]); @@ -1708,12 +1736,7 @@ static ssize_t cpu_show_common(struct de return sprintf(buf, "%s\n", spectre_v1_strings[spectre_v1_mitigation]); =20 case X86_BUG_SPECTRE_V2: - return sprintf(buf, "%s%s%s%s%s%s\n", spectre_v2_strings[spectre_v2_enab= led], - ibpb_state(), - boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ", IBRS_FW" : "", - stibp_state(), - boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? ", RSB filling" : "", - spectre_v2_module_string()); + return spectre_v2_show_state(buf); =20 case X86_BUG_SPEC_STORE_BYPASS: return sprintf(buf, "%s\n", ssb_strings[ssb_mode]); --- a/include/linux/bpf.h +++ b/include/linux/bpf.h @@ -295,6 +295,11 @@ static inline void bpf_long_memcpy(void =20 /* verify correctness of eBPF program */ int bpf_check(struct bpf_prog **fp, union bpf_attr *attr); + +static inline bool unprivileged_ebpf_enabled(void) +{ + return !sysctl_unprivileged_bpf_disabled; +} #else static inline void bpf_register_prog_type(struct bpf_prog_type_list *tl) { @@ -322,6 +327,12 @@ static inline struct bpf_prog *bpf_prog_ { return ERR_PTR(-EOPNOTSUPP); } + +static inline bool unprivileged_ebpf_enabled(void) +{ + return false; +} + #endif /* CONFIG_BPF_SYSCALL */ =20 /* verifier prototypes for helper functions called from eBPF programs */ --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -222,6 +222,11 @@ static int sysrq_sysctl_handler(struct c #endif =20 #ifdef CONFIG_BPF_SYSCALL + +void __weak unpriv_ebpf_notify(int new_state) +{ +} + static int bpf_unpriv_handler(struct ctl_table *table, int write, void *buffer, size_t *lenp, loff_t *ppos) { @@ -239,6 +244,9 @@ static int bpf_unpriv_handler(struct ctl return -EPERM; *(int *)table->data =3D unpriv_enable; } + + unpriv_ebpf_notify(unpriv_enable); + return ret; } #endif From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id ECEEFC4167B for ; Thu, 10 Mar 2022 14:20:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243094AbiCJOVu (ORCPT ); Thu, 10 Mar 2022 09:21:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243790AbiCJOSW (ORCPT ); Thu, 10 Mar 2022 09:18:22 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF001166A63; Thu, 10 Mar 2022 06:14:47 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 817ADB8267C; Thu, 10 Mar 2022 14:14:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB655C340E8; Thu, 10 Mar 2022 14:14:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921659; bh=46jo3Lac9ZQVbErqXQpZ2hY92m8kz18vN57CNImpM3g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=w24GdvgCZfFFDOl78pFEUSTB3WoXQy3ObqCWXqBbL2NQrkn2dISFtMDFqFc3nxltH MLyLKyt9QnoeV46y1NlKifCORRs0sDb5EaLO6BmUneRmaQ7LJRTZYPZyPHuJFJ4fdZ OP5uo2ADNhAmf0R2uRYFcFHI5KEA8tkA/grc9gA0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kim Phillips , Borislav Petkov , Ben Hutchings Subject: [PATCH 4.9 13/38] x86/speculation: Use generic retpoline by default on AMD Date: Thu, 10 Mar 2022 15:13:26 +0100 Message-Id: <20220310140808.524922163@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kim Phillips commit 244d00b5dd4755f8df892c86cab35fb2cfd4f14b upstream. AMD retpoline may be susceptible to speculation. The speculation execution window for an incorrect indirect branch prediction using LFENCE/JMP sequence may potentially be large enough to allow exploitation using Spectre V2. By default, don't use retpoline,lfence on AMD. Instead, use the generic retpoline. Signed-off-by: Kim Phillips Signed-off-by: Borislav Petkov Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/kernel/cpu/bugs.c | 8 -------- 1 file changed, 8 deletions(-) --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -897,14 +897,6 @@ static enum spectre_v2_mitigation __init return SPECTRE_V2_NONE; } =20 - if (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_AMD) { - if (!boot_cpu_has(X86_FEATURE_LFENCE_RDTSC)) { - pr_err("LFENCE not serializing, switching to generic retpoline\n"); - return SPECTRE_V2_RETPOLINE; - } - return SPECTRE_V2_LFENCE; - } - return SPECTRE_V2_RETPOLINE; } From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A035C433FE for ; Thu, 10 Mar 2022 14:20:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231825AbiCJOVO (ORCPT ); Thu, 10 Mar 2022 09:21:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243616AbiCJOSJ (ORCPT ); Thu, 10 Mar 2022 09:18:09 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37E22160FF0; Thu, 10 Mar 2022 06:14:24 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 967DE61B6B; Thu, 10 Mar 2022 14:14:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A60ABC340EB; Thu, 10 Mar 2022 14:14:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921662; bh=iYMuhddysstvIfw0kTZMQ+L1I5XrW+hAdLtOqnTgSXE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=t3n+2pqStT4JrVdqQjX/QhIkbhMA3QzVHsqx5qfxrt4yXwR2P2TDxGV33eE11cb6X K+eUn+cBNCxO8ALPToO/oKJATjg96RPV0wClUdFNEaO4IH21AsNy83tWBbvJCWU8cD vyxpgNkSdYnHfrUQDq3fKYmHshjKJDILTvulg0ps= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kim Phillips , Borislav Petkov , Ben Hutchings Subject: [PATCH 4.9 14/38] x86/speculation: Update link to AMD speculation whitepaper Date: Thu, 10 Mar 2022 15:13:27 +0100 Message-Id: <20220310140808.552893100@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kim Phillips commit e9b6013a7ce31535b04b02ba99babefe8a8599fa upstream. Update the link to the "Software Techniques for Managing Speculation on AMD Processors" whitepaper. Signed-off-by: Kim Phillips Signed-off-by: Borislav Petkov [bwh: Backported to 4.9: adjust filename] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- Documentation/hw-vuln/spectre.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/Documentation/hw-vuln/spectre.rst +++ b/Documentation/hw-vuln/spectre.rst @@ -60,8 +60,8 @@ privileged data touched during the specu Spectre variant 1 attacks take advantage of speculative execution of conditional branches, while Spectre variant 2 attacks use speculative execution of indirect branches to leak privileged memory. -See :ref:`[1] ` :ref:`[5] ` :ref:`[7] ` -:ref:`[10] ` :ref:`[11] `. +See :ref:`[1] ` :ref:`[5] ` :ref:`[6] ` +:ref:`[7] ` :ref:`[10] ` :ref:`[11] `. =20 Spectre variant 1 (Bounds Check Bypass) --------------------------------------- @@ -746,7 +746,7 @@ AMD white papers: =20 .. _spec_ref6: =20 -[6] `Software techniques for managing speculation on AMD processors `_. +[6] `Software techniques for managing speculation on AMD processors `_. =20 ARM white papers: From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EACC5C4332F for ; Thu, 10 Mar 2022 14:20:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242966AbiCJOVS (ORCPT ); Thu, 10 Mar 2022 09:21:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243651AbiCJOSO (ORCPT ); Thu, 10 Mar 2022 09:18:14 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A8F6A1617DD; Thu, 10 Mar 2022 06:14:27 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 33371B825F3; Thu, 10 Mar 2022 14:14:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8196CC340E8; Thu, 10 Mar 2022 14:14:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921664; bh=VTroE0o8H/coKQKT5Ucdb5Tee+fIceA46G9VPM0drL0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xc3HgE18RkWcQOi/dO6rbBqIzjOXZhBobnnAZB+0INOGBhzxzGd5cZt61wOJHo6lq uu5wFBdEhvF5LDCUqTVWQ1jfs3v8LH/LMVHNV+4xyFFYa3C/Z1aCs8dzIcIwfj8L6R RNTb3K7Q+yPcQO6SJzta8DSwVcmOfzKm2IQM5GTw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josh Poimboeuf , Borislav Petkov , Ben Hutchings Subject: [PATCH 4.9 15/38] x86/speculation: Warn about Spectre v2 LFENCE mitigation Date: Thu, 10 Mar 2022 15:13:28 +0100 Message-Id: <20220310140808.582689668@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Josh Poimboeuf commit eafd987d4a82c7bb5aa12f0e3b4f8f3dea93e678 upstream. With: f8a66d608a3e ("x86,bugs: Unconditionally allow spectre_v2=3Dretpoline,amd= ") it became possible to enable the LFENCE "retpoline" on Intel. However, Intel doesn't recommend it, as it has some weaknesses compared to retpoline. Now AMD doesn't recommend it either. It can still be left available as a cmdline option. It's faster than retpoline but is weaker in certain scenarios -- particularly SMT, but even non-SMT may be vulnerable in some cases. So just unconditionally warn if the user requests it on the cmdline. [ bp: Massage commit message. ] Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/kernel/cpu/bugs.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -607,6 +607,7 @@ static inline const char *spectre_v2_mod static inline const char *spectre_v2_module_string(void) { return ""; } #endif =20 +#define SPECTRE_V2_LFENCE_MSG "WARNING: LFENCE mitigation is not recommend= ed for this CPU, data leaks possible!\n" #define SPECTRE_V2_EIBRS_EBPF_MSG "WARNING: Unprivileged eBPF is enabled w= ith eIBRS on, data leaks possible via Spectre v2 BHB attacks!\n" =20 #ifdef CONFIG_BPF_SYSCALL @@ -928,6 +929,7 @@ static void __init spectre_v2_select_mit break; =20 case SPECTRE_V2_CMD_RETPOLINE_LFENCE: + pr_err(SPECTRE_V2_LFENCE_MSG); mode =3D SPECTRE_V2_LFENCE; break; =20 @@ -1694,6 +1696,9 @@ static char *ibpb_state(void) =20 static ssize_t spectre_v2_show_state(char *buf) { + if (spectre_v2_enabled =3D=3D SPECTRE_V2_LFENCE) + return sprintf(buf, "Vulnerable: LFENCE\n"); + if (spectre_v2_enabled =3D=3D SPECTRE_V2_EIBRS && unprivileged_ebpf_enabl= ed()) return sprintf(buf, "Vulnerable: Unprivileged eBPF enabled\n"); From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF31BC433F5 for ; Thu, 10 Mar 2022 14:23:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243650AbiCJOYq (ORCPT ); Thu, 10 Mar 2022 09:24:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243846AbiCJOS0 (ORCPT ); Thu, 10 Mar 2022 09:18:26 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA8E415678B; Thu, 10 Mar 2022 06:14:56 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 32F2EB8254A; Thu, 10 Mar 2022 14:14:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7EF86C340E8; Thu, 10 Mar 2022 14:14:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921667; bh=qJAPxXZ2TadZ/iowuZN6KPA8DnNseQ8gqYjoNpsfbrI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0uPdECukME8PYKeYHrkFTlWo7wKeKscDydMClB5DriqZsSkZzvLbU8KXqQAISx8Cd VKgrf/0CoIA23gSPm7vC2zQTx1IAKBH0bBZ8bbrPNEsVec2xvc4lqGjdrS5z1ppEst K7WzcVKcOkggHs4XF0ULmQ/UdIakNs2StZP1G7+c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alyssa Milburn , Josh Poimboeuf , Borislav Petkov , Ben Hutchings Subject: [PATCH 4.9 16/38] x86/speculation: Warn about eIBRS + LFENCE + Unprivileged eBPF + SMT Date: Thu, 10 Mar 2022 15:13:29 +0100 Message-Id: <20220310140808.611131688@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Josh Poimboeuf commit 0de05d056afdb00eca8c7bbb0c79a3438daf700c upstream. The commit 44a3918c8245 ("x86/speculation: Include unprivileged eBPF status in Spec= tre v2 mitigation reporting") added a warning for the "eIBRS + unprivileged eBPF" combination, which has been shown to be vulnerable against Spectre v2 BHB-based attacks. However, there's no warning about the "eIBRS + LFENCE retpoline + unprivileged eBPF" combo. The LFENCE adds more protection by shortening the speculation window after a mispredicted branch. That makes an attack significantly more difficult, even with unprivileged eBPF. So at least for now the logic doesn't warn about that combination. But if you then add SMT into the mix, the SMT attack angle weakens the effectiveness of the LFENCE considerably. So extend the "eIBRS + unprivileged eBPF" warning to also include the "eIBRS + LFENCE + unprivileged eBPF + SMT" case. [ bp: Massage commit message. ] Suggested-by: Alyssa Milburn Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/kernel/cpu/bugs.c | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -609,12 +609,27 @@ static inline const char *spectre_v2_mod =20 #define SPECTRE_V2_LFENCE_MSG "WARNING: LFENCE mitigation is not recommend= ed for this CPU, data leaks possible!\n" #define SPECTRE_V2_EIBRS_EBPF_MSG "WARNING: Unprivileged eBPF is enabled w= ith eIBRS on, data leaks possible via Spectre v2 BHB attacks!\n" +#define SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG "WARNING: Unprivileged eBPF i= s enabled with eIBRS+LFENCE mitigation and SMT, data leaks possible via Spe= ctre v2 BHB attacks!\n" =20 #ifdef CONFIG_BPF_SYSCALL void unpriv_ebpf_notify(int new_state) { - if (spectre_v2_enabled =3D=3D SPECTRE_V2_EIBRS && !new_state) + if (new_state) + return; + + /* Unprivileged eBPF is enabled */ + + switch (spectre_v2_enabled) { + case SPECTRE_V2_EIBRS: pr_err(SPECTRE_V2_EIBRS_EBPF_MSG); + break; + case SPECTRE_V2_EIBRS_LFENCE: + if (sched_smt_active()) + pr_err(SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG); + break; + default: + break; + } } #endif =20 @@ -1074,6 +1089,10 @@ void arch_smt_update(void) { mutex_lock(&spec_ctrl_mutex); =20 + if (sched_smt_active() && unprivileged_ebpf_enabled() && + spectre_v2_enabled =3D=3D SPECTRE_V2_EIBRS_LFENCE) + pr_warn_once(SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG); + switch (spectre_v2_user_stibp) { case SPECTRE_V2_USER_NONE: break; @@ -1700,7 +1719,11 @@ static ssize_t spectre_v2_show_state(cha return sprintf(buf, "Vulnerable: LFENCE\n"); =20 if (spectre_v2_enabled =3D=3D SPECTRE_V2_EIBRS && unprivileged_ebpf_enabl= ed()) - return sprintf(buf, "Vulnerable: Unprivileged eBPF enabled\n"); + return sprintf(buf, "Vulnerable: eIBRS with unprivileged eBPF\n"); + + if (sched_smt_active() && unprivileged_ebpf_enabled() && + spectre_v2_enabled =3D=3D SPECTRE_V2_EIBRS_LFENCE) + return sprintf(buf, "Vulnerable: eIBRS+LFENCE with unprivileged eBPF and= SMT\n"); =20 return sprintf(buf, "%s%s%s%s%s%s\n", spectre_v2_strings[spectre_v2_enabled], From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F9AEC433FE for ; Thu, 10 Mar 2022 14:23:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243680AbiCJOYu (ORCPT ); Thu, 10 Mar 2022 09:24:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243879AbiCJOS3 (ORCPT ); Thu, 10 Mar 2022 09:18:29 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F273168093; Thu, 10 Mar 2022 06:15:00 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 43976B81E9E; Thu, 10 Mar 2022 14:14:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8940FC340F4; Thu, 10 Mar 2022 14:14:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921670; bh=O/puTpS0vTBgPhZGErm9BWdP2JhT+u4Mnv+wuMe7TjM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=owIl5h8AK5ees5dIkycR3GYtX6a3widgxM33AqUczv7GycbK6/m9oPR9xELVdljaJ V8rNfvJs2hu5gcDd1+yFdnSc9v8nZQaTeIJ7IsGDPzp/m8N5KXlBiP25cS48OPok6D vBgQA7q86w4LZaBBHDy7odPzwButaZy8+SFCrc0Q= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Steven Price , Will Deacon , Marc Zyngier Subject: [PATCH 4.9 17/38] arm/arm64: Provide a wrapper for SMCCC 1.1 calls Date: Thu, 10 Mar 2022 15:13:30 +0100 Message-Id: <20220310140808.640604649@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Steven Price commit 541625ac47ce9d0835efaee0fcbaa251b0000a37 upstream. SMCCC 1.1 calls may use either HVC or SMC depending on the PSCI conduit. Rather than coding this in every call site, provide a macro which uses the correct instruction. The macro also handles the case where no conduit is configured/available returning a not supported error in res, along with returning the conduit used for the call. This allow us to remove some duplicated code and will be useful later when adding paravirtualized time hypervisor calls. Signed-off-by: Steven Price Acked-by: Will Deacon Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- include/linux/arm-smccc.h | 58 +++++++++++++++++++++++++++++++++++++++++= +++++ 1 file changed, 58 insertions(+) --- a/include/linux/arm-smccc.h +++ b/include/linux/arm-smccc.h @@ -311,5 +311,63 @@ asmlinkage void __arm_smccc_hvc(unsigned #define SMCCC_RET_NOT_SUPPORTED -1 #define SMCCC_RET_NOT_REQUIRED -2 =20 +/* + * Like arm_smccc_1_1* but always returns SMCCC_RET_NOT_SUPPORTED. + * Used when the SMCCC conduit is not defined. The empty asm statement + * avoids compiler warnings about unused variables. + */ +#define __fail_smccc_1_1(...) \ + do { \ + __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ + asm ("" __constraints(__count_args(__VA_ARGS__))); \ + if (___res) \ + ___res->a0 =3D SMCCC_RET_NOT_SUPPORTED; \ + } while (0) + +/* + * arm_smccc_1_1_invoke() - make an SMCCC v1.1 compliant call + * + * This is a variadic macro taking one to eight source arguments, and + * an optional return structure. + * + * @a0-a7: arguments passed in registers 0 to 7 + * @res: result values from registers 0 to 3 + * + * This macro will make either an HVC call or an SMC call depending on the + * current SMCCC conduit. If no valid conduit is available then -1 + * (SMCCC_RET_NOT_SUPPORTED) is returned in @res.a0 (if supplied). + * + * The return value also provides the conduit that was used. + */ +#define arm_smccc_1_1_invoke(...) ({ \ + int method =3D arm_smccc_1_1_get_conduit(); \ + switch (method) { \ + case SMCCC_CONDUIT_HVC: \ + arm_smccc_1_1_hvc(__VA_ARGS__); \ + break; \ + case SMCCC_CONDUIT_SMC: \ + arm_smccc_1_1_smc(__VA_ARGS__); \ + break; \ + default: \ + __fail_smccc_1_1(__VA_ARGS__); \ + method =3D SMCCC_CONDUIT_NONE; \ + break; \ + } \ + method; \ + }) + +/* Paravirtualised time calls (defined by ARM DEN0057A) */ +#define ARM_SMCCC_HV_PV_TIME_FEATURES \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \ + ARM_SMCCC_SMC_64, \ + ARM_SMCCC_OWNER_STANDARD_HYP, \ + 0x20) + +#define ARM_SMCCC_HV_PV_TIME_ST \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \ + ARM_SMCCC_SMC_64, \ + ARM_SMCCC_OWNER_STANDARD_HYP, \ + 0x21) + #endif /*__ASSEMBLY__*/ #endif /*__LINUX_ARM_SMCCC_H*/ From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CBBB1C433EF for ; Thu, 10 Mar 2022 14:21:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230047AbiCJOWP (ORCPT ); Thu, 10 Mar 2022 09:22:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43442 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243910AbiCJOSb (ORCPT ); Thu, 10 Mar 2022 09:18:31 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 32F091688F1; Thu, 10 Mar 2022 06:15:02 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B121361CB3; Thu, 10 Mar 2022 14:14:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9EBB7C340E8; Thu, 10 Mar 2022 14:14:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921674; bh=hgyMPXKpyrjFSr7gjjGkb1FgtZRbJo9afPZLy+xNAuM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eprQ0ANWH16zx2V159h2X2ZSpA3yECWdK2mm63oXVo7ullQIcUzwu7jw8oKpBDDAU AV69or/YLWYkqaBKClI/I06s/CEM3FyQFjS8tVb3debUX55ni8mRj6JAoV+R25ID5U 4uBwgL402uLQVu6MFphGlaZjPvDCYhjlZnS46ld4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mark Rutland , Lorenzo Pieralisi , Will Deacon , Catalin Marinas Subject: [PATCH 4.9 18/38] arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit() Date: Thu, 10 Mar 2022 15:13:31 +0100 Message-Id: <20220310140808.670724871@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Mark Rutland commit 6b7fe77c334ae59fed9500140e08f4f896b36871 upstream. SMCCC callers are currently amassing a collection of enums for the SMCCC conduit, and are having to dig into the PSCI driver's internals in order to figure out what to do. Let's clean this up, with common SMCCC_CONDUIT_* definitions, and an arm_smccc_1_1_get_conduit() helper that abstracts the PSCI driver's internal state. We can kill off the PSCI_CONDUIT_* definitions once we've migrated users over to the new interface. Signed-off-by: Mark Rutland Acked-by: Lorenzo Pieralisi Acked-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- drivers/firmware/psci.c | 15 +++++++++++++++ include/linux/arm-smccc.h | 16 ++++++++++++++++ 2 files changed, 31 insertions(+) --- a/drivers/firmware/psci.c +++ b/drivers/firmware/psci.c @@ -64,6 +64,21 @@ struct psci_operations psci_ops =3D { .smccc_version =3D SMCCC_VERSION_1_0, }; =20 +enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void) +{ + if (psci_ops.smccc_version < SMCCC_VERSION_1_1) + return SMCCC_CONDUIT_NONE; + + switch (psci_ops.conduit) { + case PSCI_CONDUIT_SMC: + return SMCCC_CONDUIT_SMC; + case PSCI_CONDUIT_HVC: + return SMCCC_CONDUIT_HVC; + default: + return SMCCC_CONDUIT_NONE; + } +} + typedef unsigned long (psci_fn)(unsigned long, unsigned long, unsigned long, unsigned long); static psci_fn *invoke_psci_fn; --- a/include/linux/arm-smccc.h +++ b/include/linux/arm-smccc.h @@ -89,6 +89,22 @@ =20 #include #include + +enum arm_smccc_conduit { + SMCCC_CONDUIT_NONE, + SMCCC_CONDUIT_SMC, + SMCCC_CONDUIT_HVC, +}; + +/** + * arm_smccc_1_1_get_conduit() + * + * Returns the conduit to be used for SMCCCv1.1 or later. + * + * When SMCCCv1.1 is not present, returns SMCCC_CONDUIT_NONE. + */ +enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void); + /** * struct arm_smccc_res - Result from SMC/HVC call * @a0-a3 result values from registers 0 to 3 From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85650C4167D for ; Thu, 10 Mar 2022 14:20:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243362AbiCJOVp (ORCPT ); Thu, 10 Mar 2022 09:21:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243745AbiCJOSU (ORCPT ); Thu, 10 Mar 2022 09:18:20 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F225D1662C0; Thu, 10 Mar 2022 06:14:39 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B92B461C7B; Thu, 10 Mar 2022 14:14:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8C43C340E8; Thu, 10 Mar 2022 14:14:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921677; bh=hUAio2j7eMsQbTwI5mHPWJIU4Rc0iNayJZ8io4YTexw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OmHb790szhpQjz6cCj95bmkd9D28Bt6vwCZps11GXT1cyRNFm4GQgGyhkxcTv75T9 rQwhwEqS5c9WhKQWB1rU4puKxXnZugxDR4FCC+EeIPq7yLO4qS/lUy+Ki0PzUspY91 gZIi8x4AxHpEJrAdCtl6w7JN9sPngLN8DQ2bievI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Catalin Marinas , "Russell King (Oracle)" Subject: [PATCH 4.9 19/38] ARM: report Spectre v2 status through sysfs Date: Thu, 10 Mar 2022 15:13:32 +0100 Message-Id: <20220310140808.699465325@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "Russell King (Oracle)" commit 9dd78194a3722fa6712192cdd4f7032d45112a9a upstream. As per other architectures, add support for reporting the Spectre vulnerability status via sysfs CPU. Acked-by: Catalin Marinas Signed-off-by: Russell King (Oracle) [ preserve res variable and add SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED - greg= kh ] Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/arm/include/asm/spectre.h | 28 ++++++++ arch/arm/kernel/Makefile | 2=20 arch/arm/kernel/spectre.c | 54 +++++++++++++++++ arch/arm/mm/Kconfig | 1=20 arch/arm/mm/proc-v7-bugs.c | 130 +++++++++++++++++++++++++++++++-----= ----- 5 files changed, 184 insertions(+), 31 deletions(-) create mode 100644 arch/arm/include/asm/spectre.h create mode 100644 arch/arm/kernel/spectre.c --- /dev/null +++ b/arch/arm/include/asm/spectre.h @@ -0,0 +1,28 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef __ASM_SPECTRE_H +#define __ASM_SPECTRE_H + +enum { + SPECTRE_UNAFFECTED, + SPECTRE_MITIGATED, + SPECTRE_VULNERABLE, +}; + +enum { + __SPECTRE_V2_METHOD_BPIALL, + __SPECTRE_V2_METHOD_ICIALLU, + __SPECTRE_V2_METHOD_SMC, + __SPECTRE_V2_METHOD_HVC, +}; + +enum { + SPECTRE_V2_METHOD_BPIALL =3D BIT(__SPECTRE_V2_METHOD_BPIALL), + SPECTRE_V2_METHOD_ICIALLU =3D BIT(__SPECTRE_V2_METHOD_ICIALLU), + SPECTRE_V2_METHOD_SMC =3D BIT(__SPECTRE_V2_METHOD_SMC), + SPECTRE_V2_METHOD_HVC =3D BIT(__SPECTRE_V2_METHOD_HVC), +}; + +void spectre_v2_update_state(unsigned int state, unsigned int methods); + +#endif --- a/arch/arm/kernel/Makefile +++ b/arch/arm/kernel/Makefile @@ -100,4 +100,6 @@ endif =20 obj-$(CONFIG_HAVE_ARM_SMCCC) +=3D smccc-call.o =20 +obj-$(CONFIG_GENERIC_CPU_VULNERABILITIES) +=3D spectre.o + extra-y :=3D $(head-y) vmlinux.lds --- /dev/null +++ b/arch/arm/kernel/spectre.c @@ -0,0 +1,54 @@ +// SPDX-License-Identifier: GPL-2.0-only +#include +#include + +#include + +ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *a= ttr, + char *buf) +{ + return sprintf(buf, "Mitigation: __user pointer sanitization\n"); +} + +static unsigned int spectre_v2_state; +static unsigned int spectre_v2_methods; + +void spectre_v2_update_state(unsigned int state, unsigned int method) +{ + if (state > spectre_v2_state) + spectre_v2_state =3D state; + spectre_v2_methods |=3D method; +} + +ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *a= ttr, + char *buf) +{ + const char *method; + + if (spectre_v2_state =3D=3D SPECTRE_UNAFFECTED) + return sprintf(buf, "%s\n", "Not affected"); + + if (spectre_v2_state !=3D SPECTRE_MITIGATED) + return sprintf(buf, "%s\n", "Vulnerable"); + + switch (spectre_v2_methods) { + case SPECTRE_V2_METHOD_BPIALL: + method =3D "Branch predictor hardening"; + break; + + case SPECTRE_V2_METHOD_ICIALLU: + method =3D "I-cache invalidation"; + break; + + case SPECTRE_V2_METHOD_SMC: + case SPECTRE_V2_METHOD_HVC: + method =3D "Firmware call"; + break; + + default: + method =3D "Multiple mitigations"; + break; + } + + return sprintf(buf, "Mitigation: %s\n", method); +} --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -803,6 +803,7 @@ config CPU_BPREDICT_DISABLE =20 config CPU_SPECTRE bool + select GENERIC_CPU_VULNERABILITIES =20 config HARDEN_BRANCH_PREDICTOR bool "Harden the branch predictor against aliasing attacks" if EXPERT --- a/arch/arm/mm/proc-v7-bugs.c +++ b/arch/arm/mm/proc-v7-bugs.c @@ -7,8 +7,36 @@ #include #include #include +#include #include =20 +#ifdef CONFIG_ARM_PSCI +#define SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED 1 +static int __maybe_unused spectre_v2_get_cpu_fw_mitigation_state(void) +{ + struct arm_smccc_res res; + + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID, + ARM_SMCCC_ARCH_WORKAROUND_1, &res); + + switch ((int)res.a0) { + case SMCCC_RET_SUCCESS: + return SPECTRE_MITIGATED; + + case SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED: + return SPECTRE_UNAFFECTED; + + default: + return SPECTRE_VULNERABLE; + } +} +#else +static int __maybe_unused spectre_v2_get_cpu_fw_mitigation_state(void) +{ + return SPECTRE_VULNERABLE; +} +#endif + #ifdef CONFIG_HARDEN_BRANCH_PREDICTOR DEFINE_PER_CPU(harden_branch_predictor_fn_t, harden_branch_predictor_fn); =20 @@ -37,13 +65,60 @@ static void __maybe_unused call_hvc_arch arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL); } =20 -static void cpu_v7_spectre_init(void) +static unsigned int spectre_v2_install_workaround(unsigned int method) { const char *spectre_v2_method =3D NULL; int cpu =3D smp_processor_id(); =20 if (per_cpu(harden_branch_predictor_fn, cpu)) - return; + return SPECTRE_MITIGATED; + + switch (method) { + case SPECTRE_V2_METHOD_BPIALL: + per_cpu(harden_branch_predictor_fn, cpu) =3D + harden_branch_predictor_bpiall; + spectre_v2_method =3D "BPIALL"; + break; + + case SPECTRE_V2_METHOD_ICIALLU: + per_cpu(harden_branch_predictor_fn, cpu) =3D + harden_branch_predictor_iciallu; + spectre_v2_method =3D "ICIALLU"; + break; + + case SPECTRE_V2_METHOD_HVC: + per_cpu(harden_branch_predictor_fn, cpu) =3D + call_hvc_arch_workaround_1; + cpu_do_switch_mm =3D cpu_v7_hvc_switch_mm; + spectre_v2_method =3D "hypervisor"; + break; + + case SPECTRE_V2_METHOD_SMC: + per_cpu(harden_branch_predictor_fn, cpu) =3D + call_smc_arch_workaround_1; + cpu_do_switch_mm =3D cpu_v7_smc_switch_mm; + spectre_v2_method =3D "firmware"; + break; + } + + if (spectre_v2_method) + pr_info("CPU%u: Spectre v2: using %s workaround\n", + smp_processor_id(), spectre_v2_method); + + return SPECTRE_MITIGATED; +} +#else +static unsigned int spectre_v2_install_workaround(unsigned int method) +{ + pr_info("CPU%u: Spectre V2: workarounds disabled by configuration\n"); + + return SPECTRE_VULNERABLE; +} +#endif + +static void cpu_v7_spectre_v2_init(void) +{ + unsigned int state, method =3D 0; =20 switch (read_cpuid_part()) { case ARM_CPU_PART_CORTEX_A8: @@ -52,29 +127,32 @@ static void cpu_v7_spectre_init(void) case ARM_CPU_PART_CORTEX_A17: case ARM_CPU_PART_CORTEX_A73: case ARM_CPU_PART_CORTEX_A75: - per_cpu(harden_branch_predictor_fn, cpu) =3D - harden_branch_predictor_bpiall; - spectre_v2_method =3D "BPIALL"; + state =3D SPECTRE_MITIGATED; + method =3D SPECTRE_V2_METHOD_BPIALL; break; =20 case ARM_CPU_PART_CORTEX_A15: case ARM_CPU_PART_BRAHMA_B15: - per_cpu(harden_branch_predictor_fn, cpu) =3D - harden_branch_predictor_iciallu; - spectre_v2_method =3D "ICIALLU"; + state =3D SPECTRE_MITIGATED; + method =3D SPECTRE_V2_METHOD_ICIALLU; break; =20 -#ifdef CONFIG_ARM_PSCI default: /* Other ARM CPUs require no workaround */ - if (read_cpuid_implementor() =3D=3D ARM_CPU_IMP_ARM) + if (read_cpuid_implementor() =3D=3D ARM_CPU_IMP_ARM) { + state =3D SPECTRE_UNAFFECTED; break; + } /* fallthrough */ - /* Cortex A57/A72 require firmware workaround */ + /* Cortex A57/A72 require firmware workaround */ case ARM_CPU_PART_CORTEX_A57: case ARM_CPU_PART_CORTEX_A72: { struct arm_smccc_res res; =20 + state =3D spectre_v2_get_cpu_fw_mitigation_state(); + if (state !=3D SPECTRE_MITIGATED) + break; + if (psci_ops.smccc_version =3D=3D SMCCC_VERSION_1_0) break; =20 @@ -84,10 +162,7 @@ static void cpu_v7_spectre_init(void) ARM_SMCCC_ARCH_WORKAROUND_1, &res); if ((int)res.a0 !=3D 0) break; - per_cpu(harden_branch_predictor_fn, cpu) =3D - call_hvc_arch_workaround_1; - cpu_do_switch_mm =3D cpu_v7_hvc_switch_mm; - spectre_v2_method =3D "hypervisor"; + method =3D SPECTRE_V2_METHOD_HVC; break; =20 case PSCI_CONDUIT_SMC: @@ -95,28 +170,21 @@ static void cpu_v7_spectre_init(void) ARM_SMCCC_ARCH_WORKAROUND_1, &res); if ((int)res.a0 !=3D 0) break; - per_cpu(harden_branch_predictor_fn, cpu) =3D - call_smc_arch_workaround_1; - cpu_do_switch_mm =3D cpu_v7_smc_switch_mm; - spectre_v2_method =3D "firmware"; + method =3D SPECTRE_V2_METHOD_SMC; break; =20 default: + state =3D SPECTRE_VULNERABLE; break; } } -#endif } =20 - if (spectre_v2_method) - pr_info("CPU%u: Spectre v2: using %s workaround\n", - smp_processor_id(), spectre_v2_method); -} -#else -static void cpu_v7_spectre_init(void) -{ + if (state =3D=3D SPECTRE_MITIGATED) + state =3D spectre_v2_install_workaround(method); + + spectre_v2_update_state(state, method); } -#endif =20 static __maybe_unused bool cpu_v7_check_auxcr_set(bool *warned, u32 mask, const char *msg) @@ -146,16 +214,16 @@ static bool check_spectre_auxcr(bool *wa void cpu_v7_ca8_ibe(void) { if (check_spectre_auxcr(this_cpu_ptr(&spectre_warned), BIT(6))) - cpu_v7_spectre_init(); + cpu_v7_spectre_v2_init(); } =20 void cpu_v7_ca15_ibe(void) { if (check_spectre_auxcr(this_cpu_ptr(&spectre_warned), BIT(0))) - cpu_v7_spectre_init(); + cpu_v7_spectre_v2_init(); } =20 void cpu_v7_bugs_init(void) { - cpu_v7_spectre_init(); + cpu_v7_spectre_v2_init(); } From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97BC8C433F5 for ; Thu, 10 Mar 2022 14:21:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241901AbiCJOWA (ORCPT ); Thu, 10 Mar 2022 09:22:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243841AbiCJOSZ (ORCPT ); Thu, 10 Mar 2022 09:18:25 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D37F6158DA5; Thu, 10 Mar 2022 06:14:56 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 97626B8267F; Thu, 10 Mar 2022 14:14:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DDF44C340E8; Thu, 10 Mar 2022 14:14:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921688; bh=MXzJc6tTNRtXvc8e7ywF9mKWYhF9eLEQl9GE1I8MWLk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eq8HXcPFHUT8A1hLKG4555UVTkqzGECbxSjiPVm5NkcNQnF5LEWuRoycvcSE8QqQa 8hHY+MNol3fp06SnPYSE9Bz1Vorgcp4ArEvgbGq3TpNmiq71WlSPnf3UcKCx9VshCK gZs+sk/9yCgiuCfliPKsf2d0z954PPLQYeuQhVt8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Catalin Marinas , "Russell King (Oracle)" Subject: [PATCH 4.9 20/38] ARM: early traps initialisation Date: Thu, 10 Mar 2022 15:13:33 +0100 Message-Id: <20220310140808.728100502@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "Russell King (Oracle)" commit 04e91b7324760a377a725e218b5ee783826d30f5 upstream. Provide a couple of helpers to copy the vectors and stubs, and also to flush the copied vectors and stubs. Acked-by: Catalin Marinas Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/arm/kernel/traps.c | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-) --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -819,10 +819,22 @@ static inline void __init kuser_init(voi } #endif =20 +#ifndef CONFIG_CPU_V7M +static void copy_from_lma(void *vma, void *lma_start, void *lma_end) +{ + memcpy(vma, lma_start, lma_end - lma_start); +} + +static void flush_vectors(void *vma, size_t offset, size_t size) +{ + unsigned long start =3D (unsigned long)vma + offset; + unsigned long end =3D start + size; + + flush_icache_range(start, end); +} + void __init early_trap_init(void *vectors_base) { -#ifndef CONFIG_CPU_V7M - unsigned long vectors =3D (unsigned long)vectors_base; extern char __stubs_start[], __stubs_end[]; extern char __vectors_start[], __vectors_end[]; unsigned i; @@ -843,17 +855,20 @@ void __init early_trap_init(void *vector * into the vector page, mapped at 0xffff0000, and ensure these * are visible to the instruction stream. */ - memcpy((void *)vectors, __vectors_start, __vectors_end - __vectors_start); - memcpy((void *)vectors + 0x1000, __stubs_start, __stubs_end - __stubs_sta= rt); + copy_from_lma(vectors_base, __vectors_start, __vectors_end); + copy_from_lma(vectors_base + 0x1000, __stubs_start, __stubs_end); =20 kuser_init(vectors_base); =20 - flush_icache_range(vectors, vectors + PAGE_SIZE * 2); + flush_vectors(vectors_base, 0, PAGE_SIZE * 2); +} #else /* ifndef CONFIG_CPU_V7M */ +void __init early_trap_init(void *vectors_base) +{ /* * on V7-M there is no need to copy the vector table to a dedicated * memory area. The address is configurable and so a table in the kernel * image can be used. */ -#endif } +#endif From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F27BC433EF for ; Thu, 10 Mar 2022 14:21:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243459AbiCJOWf (ORCPT ); Thu, 10 Mar 2022 09:22:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38686 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243970AbiCJOSd (ORCPT ); Thu, 10 Mar 2022 09:18:33 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88F38154D24; Thu, 10 Mar 2022 06:15:12 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CA87C61B63; Thu, 10 Mar 2022 14:14:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7668C340E8; Thu, 10 Mar 2022 14:14:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921691; bh=a/dB2UmD78+I6BqAfk2Y/X4e14BkMc2n+CsySWaMTLI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WliLG4ULuyiOJ+RQnn7j36HoYYEeF2igKmQ9N9mJL/vzX9VSGDwl/kEQCgcrup1GQ InYzYpX/tE6FvYz8DSTOJKX1XcUgtZW5QSKN9yCYGGUjBFX1kIH8ekkezawAPdEfSU y7yauOoML+jVotLHEGj2uiEIh0zSXmCSyTa59vhA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Catalin Marinas , "Russell King (Oracle)" Subject: [PATCH 4.9 21/38] ARM: use LOADADDR() to get load address of sections Date: Thu, 10 Mar 2022 15:13:34 +0100 Message-Id: <20220310140808.757214111@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "Russell King (Oracle)" commit 8d9d651ff2270a632e9dc497b142db31e8911315 upstream. Use the linker's LOADADDR() macro to get the load address of the sections, and provide a macro to set the start and end symbols. Acked-by: Catalin Marinas Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/arm/kernel/vmlinux-xip.lds.S | 19 ++++++++++++------- arch/arm/kernel/vmlinux.lds.S | 19 ++++++++++++------- 2 files changed, 24 insertions(+), 14 deletions(-) --- a/arch/arm/kernel/vmlinux-xip.lds.S +++ b/arch/arm/kernel/vmlinux-xip.lds.S @@ -12,6 +12,11 @@ #include #include =20 +/* Set start/end symbol names to the LMA for the section */ +#define ARM_LMA(sym, section) \ + sym##_start =3D LOADADDR(section); \ + sym##_end =3D LOADADDR(section) + SIZEOF(section) + #define PROC_INFO \ . =3D ALIGN(4); \ VMLINUX_SYMBOL(__proc_info_begin) =3D .; \ @@ -148,19 +153,19 @@ SECTIONS * The vectors and stubs are relocatable code, and the * only thing that matters is their relative offsets */ - __vectors_start =3D .; + __vectors_lma =3D .; .vectors 0xffff0000 : AT(__vectors_start) { *(.vectors) } - . =3D __vectors_start + SIZEOF(.vectors); - __vectors_end =3D .; + ARM_LMA(__vectors, .vectors); + . =3D __vectors_lma + SIZEOF(.vectors); =20 - __stubs_start =3D .; - .stubs ADDR(.vectors) + 0x1000 : AT(__stubs_start) { + __stubs_lma =3D .; + .stubs ADDR(.vectors) + 0x1000 : AT(__stubs_lma) { *(.stubs) } - . =3D __stubs_start + SIZEOF(.stubs); - __stubs_end =3D .; + ARM_LMA(__stubs, .stubs); + . =3D __stubs_lma + SIZEOF(.stubs); =20 PROVIDE(vector_fiq_offset =3D vector_fiq - ADDR(.vectors)); =20 --- a/arch/arm/kernel/vmlinux.lds.S +++ b/arch/arm/kernel/vmlinux.lds.S @@ -14,6 +14,11 @@ #include #include =20 +/* Set start/end symbol names to the LMA for the section */ +#define ARM_LMA(sym, section) \ + sym##_start =3D LOADADDR(section); \ + sym##_end =3D LOADADDR(section) + SIZEOF(section) + #define PROC_INFO \ . =3D ALIGN(4); \ VMLINUX_SYMBOL(__proc_info_begin) =3D .; \ @@ -169,19 +174,19 @@ SECTIONS * The vectors and stubs are relocatable code, and the * only thing that matters is their relative offsets */ - __vectors_start =3D .; + __vectors_lma =3D .; .vectors 0xffff0000 : AT(__vectors_start) { *(.vectors) } - . =3D __vectors_start + SIZEOF(.vectors); - __vectors_end =3D .; + ARM_LMA(__vectors, .vectors); + . =3D __vectors_lma + SIZEOF(.vectors); =20 - __stubs_start =3D .; - .stubs ADDR(.vectors) + 0x1000 : AT(__stubs_start) { + __stubs_lma =3D .; + .stubs ADDR(.vectors) + 0x1000 : AT(__stubs_lma) { *(.stubs) } - . =3D __stubs_start + SIZEOF(.stubs); - __stubs_end =3D .; + ARM_LMA(__stubs, .stubs); + . =3D __stubs_lma + SIZEOF(.stubs); =20 PROVIDE(vector_fiq_offset =3D vector_fiq - ADDR(.vectors)); From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCA41C433EF for ; Thu, 10 Mar 2022 14:21:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243349AbiCJOWJ (ORCPT ); Thu, 10 Mar 2022 09:22:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243840AbiCJOSZ (ORCPT ); Thu, 10 Mar 2022 09:18:25 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B009164D07; Thu, 10 Mar 2022 06:14:55 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D31B061B5F; Thu, 10 Mar 2022 14:14:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0D15C340E8; Thu, 10 Mar 2022 14:14:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921694; bh=RdlkYlxX79Hp72yP22r1ygzkblTZ+Jb1feQOE4RuZsE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aHsbGIPrfZjd4bWbcF1lR5YgXL9iyxa6+NTcpUb7Y65KgQL7oCKkmRpxfypAIsPt9 3h/Vb5/FpOX4tQ62Zy7iR+8t+zExmc0/ZibV/IBBJZhoUNEX5g6YUqO6Wdb/OTtwN2 o7F2hmygVP1aRyKGBDuIRFUqOfsNLQH9Y1Qk5pig= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Catalin Marinas , "Russell King (Oracle)" Subject: [PATCH 4.9 22/38] ARM: Spectre-BHB workaround Date: Thu, 10 Mar 2022 15:13:35 +0100 Message-Id: <20220310140808.785589291@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "Russell King (Oracle)" commit b9baf5c8c5c356757f4f9d8180b5e9d234065bc3 upstream. Workaround the Spectre BHB issues for Cortex-A15, Cortex-A57, Cortex-A72, Cortex-A73 and Cortex-A75. We also include Brahma B15 as well to be safe, which is affected by Spectre V2 in the same ways as Cortex-A15. Reviewed-by: Catalin Marinas Signed-off-by: Russell King (Oracle) [changes due to lack of SYSTEM_FREEING_INITMEM - gregkh] Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/arm/include/asm/assembler.h | 10 ++++ arch/arm/include/asm/spectre.h | 4 + arch/arm/kernel/entry-armv.S | 79 +++++++++++++++++++++++++++++++++= ++--- arch/arm/kernel/entry-common.S | 24 +++++++++++ arch/arm/kernel/spectre.c | 4 + arch/arm/kernel/traps.c | 38 ++++++++++++++++++ arch/arm/kernel/vmlinux-xip.lds.S | 18 +++++++- arch/arm/kernel/vmlinux.lds.S | 18 +++++++- arch/arm/mm/Kconfig | 10 ++++ arch/arm/mm/proc-v7-bugs.c | 76 +++++++++++++++++++++++++++++++++= +++ 10 files changed, 269 insertions(+), 12 deletions(-) --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -108,6 +108,16 @@ .endm #endif =20 +#if __LINUX_ARM_ARCH__ < 7 + .macro dsb, args + mcr p15, 0, r0, c7, c10, 4 + .endm + + .macro isb, args + mcr p15, 0, r0, c7, r5, 4 + .endm +#endif + .macro asm_trace_hardirqs_off, save=3D1 #if defined(CONFIG_TRACE_IRQFLAGS) .if \save --- a/arch/arm/include/asm/spectre.h +++ b/arch/arm/include/asm/spectre.h @@ -14,6 +14,7 @@ enum { __SPECTRE_V2_METHOD_ICIALLU, __SPECTRE_V2_METHOD_SMC, __SPECTRE_V2_METHOD_HVC, + __SPECTRE_V2_METHOD_LOOP8, }; =20 enum { @@ -21,8 +22,11 @@ enum { SPECTRE_V2_METHOD_ICIALLU =3D BIT(__SPECTRE_V2_METHOD_ICIALLU), SPECTRE_V2_METHOD_SMC =3D BIT(__SPECTRE_V2_METHOD_SMC), SPECTRE_V2_METHOD_HVC =3D BIT(__SPECTRE_V2_METHOD_HVC), + SPECTRE_V2_METHOD_LOOP8 =3D BIT(__SPECTRE_V2_METHOD_LOOP8), }; =20 void spectre_v2_update_state(unsigned int state, unsigned int methods); =20 +int spectre_bhb_update_vectors(unsigned int method); + #endif --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -1036,12 +1036,11 @@ vector_\name: sub lr, lr, #\correction .endif =20 - @ - @ Save r0, lr_ (parent PC) and spsr_ - @ (parent CPSR) - @ + @ Save r0, lr_ (parent PC) stmia sp, {r0, lr} @ save r0, lr - mrs lr, spsr + + @ Save spsr_ (parent CPSR) +2: mrs lr, spsr str lr, [sp, #8] @ save spsr =20 @ @@ -1062,6 +1061,44 @@ vector_\name: movs pc, lr @ branch to handler in SVC mode ENDPROC(vector_\name) =20 +#ifdef CONFIG_HARDEN_BRANCH_HISTORY + .subsection 1 + .align 5 +vector_bhb_loop8_\name: + .if \correction + sub lr, lr, #\correction + .endif + + @ Save r0, lr_ (parent PC) + stmia sp, {r0, lr} + + @ bhb workaround + mov r0, #8 +1: b . + 4 + subs r0, r0, #1 + bne 1b + dsb + isb + b 2b +ENDPROC(vector_bhb_loop8_\name) + +vector_bhb_bpiall_\name: + .if \correction + sub lr, lr, #\correction + .endif + + @ Save r0, lr_ (parent PC) + stmia sp, {r0, lr} + + @ bhb workaround + mcr p15, 0, r0, c7, c5, 6 @ BPIALL + @ isb not needed due to "movs pc, lr" in the vector stub + @ which gives a "context synchronisation". + b 2b +ENDPROC(vector_bhb_bpiall_\name) + .previous +#endif + .align 2 @ handler addresses follow this label 1: @@ -1070,6 +1107,10 @@ ENDPROC(vector_\name) .section .stubs, "ax", %progbits @ This must be the first word .word vector_swi +#ifdef CONFIG_HARDEN_BRANCH_HISTORY + .word vector_bhb_loop8_swi + .word vector_bhb_bpiall_swi +#endif =20 vector_rst: ARM( swi SYS_ERROR0 ) @@ -1184,8 +1225,10 @@ vector_addrexcptn: * FIQ "NMI" handler *------------------------------------------------------------------------= ----- * Handle a FIQ using the SVC stack allowing FIQ act like NMI on x86 - * systems. + * systems. This must be the last vector stub, so lets place it in its own + * subsection. */ + .subsection 2 vector_stub fiq, FIQ_MODE, 4 =20 .long __fiq_usr @ 0 (USR_26 / USR_32) @@ -1218,6 +1261,30 @@ vector_addrexcptn: W(b) vector_irq W(b) vector_fiq =20 +#ifdef CONFIG_HARDEN_BRANCH_HISTORY + .section .vectors.bhb.loop8, "ax", %progbits +.L__vectors_bhb_loop8_start: + W(b) vector_rst + W(b) vector_bhb_loop8_und + W(ldr) pc, .L__vectors_bhb_loop8_start + 0x1004 + W(b) vector_bhb_loop8_pabt + W(b) vector_bhb_loop8_dabt + W(b) vector_addrexcptn + W(b) vector_bhb_loop8_irq + W(b) vector_bhb_loop8_fiq + + .section .vectors.bhb.bpiall, "ax", %progbits +.L__vectors_bhb_bpiall_start: + W(b) vector_rst + W(b) vector_bhb_bpiall_und + W(ldr) pc, .L__vectors_bhb_bpiall_start + 0x1008 + W(b) vector_bhb_bpiall_pabt + W(b) vector_bhb_bpiall_dabt + W(b) vector_addrexcptn + W(b) vector_bhb_bpiall_irq + W(b) vector_bhb_bpiall_fiq +#endif + .data =20 .globl cr_alignment --- a/arch/arm/kernel/entry-common.S +++ b/arch/arm/kernel/entry-common.S @@ -143,12 +143,36 @@ ENDPROC(ret_from_fork) */ =20 .align 5 +#ifdef CONFIG_HARDEN_BRANCH_HISTORY +ENTRY(vector_bhb_loop8_swi) + sub sp, sp, #PT_REGS_SIZE + stmia sp, {r0 - r12} + mov r8, #8 +1: b 2f +2: subs r8, r8, #1 + bne 1b + dsb + isb + b 3f +ENDPROC(vector_bhb_loop8_swi) + + .align 5 +ENTRY(vector_bhb_bpiall_swi) + sub sp, sp, #PT_REGS_SIZE + stmia sp, {r0 - r12} + mcr p15, 0, r8, c7, c5, 6 @ BPIALL + isb + b 3f +ENDPROC(vector_bhb_bpiall_swi) +#endif + .align 5 ENTRY(vector_swi) #ifdef CONFIG_CPU_V7M v7m_exception_entry #else sub sp, sp, #PT_REGS_SIZE stmia sp, {r0 - r12} @ Calling r0 - r12 +3: ARM( add r8, sp, #S_PC ) ARM( stmdb r8, {sp, lr}^ ) @ Calling sp, lr THUMB( mov r8, sp ) --- a/arch/arm/kernel/spectre.c +++ b/arch/arm/kernel/spectre.c @@ -45,6 +45,10 @@ ssize_t cpu_show_spectre_v2(struct devic method =3D "Firmware call"; break; =20 + case SPECTRE_V2_METHOD_LOOP8: + method =3D "History overwrite"; + break; + default: method =3D "Multiple mitigations"; break; --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -833,6 +834,43 @@ static void flush_vectors(void *vma, siz flush_icache_range(start, end); } =20 +#ifdef CONFIG_HARDEN_BRANCH_HISTORY +int spectre_bhb_update_vectors(unsigned int method) +{ + extern char __vectors_bhb_bpiall_start[], __vectors_bhb_bpiall_end[]; + extern char __vectors_bhb_loop8_start[], __vectors_bhb_loop8_end[]; + void *vec_start, *vec_end; + + if (system_state >=3D SYSTEM_RUNNING) { + pr_err("CPU%u: Spectre BHB workaround too late - system vulnerable\n", + smp_processor_id()); + return SPECTRE_VULNERABLE; + } + + switch (method) { + case SPECTRE_V2_METHOD_LOOP8: + vec_start =3D __vectors_bhb_loop8_start; + vec_end =3D __vectors_bhb_loop8_end; + break; + + case SPECTRE_V2_METHOD_BPIALL: + vec_start =3D __vectors_bhb_bpiall_start; + vec_end =3D __vectors_bhb_bpiall_end; + break; + + default: + pr_err("CPU%u: unknown Spectre BHB state %d\n", + smp_processor_id(), method); + return SPECTRE_VULNERABLE; + } + + copy_from_lma(vectors_page, vec_start, vec_end); + flush_vectors(vectors_page, 0, vec_end - vec_start); + + return SPECTRE_MITIGATED; +} +#endif + void __init early_trap_init(void *vectors_base) { extern char __stubs_start[], __stubs_end[]; --- a/arch/arm/kernel/vmlinux-xip.lds.S +++ b/arch/arm/kernel/vmlinux-xip.lds.S @@ -154,11 +154,23 @@ SECTIONS * only thing that matters is their relative offsets */ __vectors_lma =3D .; - .vectors 0xffff0000 : AT(__vectors_start) { - *(.vectors) + OVERLAY 0xffff0000 : NOCROSSREFS AT(__vectors_lma) { + .vectors { + *(.vectors) + } + .vectors.bhb.loop8 { + *(.vectors.bhb.loop8) + } + .vectors.bhb.bpiall { + *(.vectors.bhb.bpiall) + } } ARM_LMA(__vectors, .vectors); - . =3D __vectors_lma + SIZEOF(.vectors); + ARM_LMA(__vectors_bhb_loop8, .vectors.bhb.loop8); + ARM_LMA(__vectors_bhb_bpiall, .vectors.bhb.bpiall); + . =3D __vectors_lma + SIZEOF(.vectors) + + SIZEOF(.vectors.bhb.loop8) + + SIZEOF(.vectors.bhb.bpiall); =20 __stubs_lma =3D .; .stubs ADDR(.vectors) + 0x1000 : AT(__stubs_lma) { --- a/arch/arm/kernel/vmlinux.lds.S +++ b/arch/arm/kernel/vmlinux.lds.S @@ -175,11 +175,23 @@ SECTIONS * only thing that matters is their relative offsets */ __vectors_lma =3D .; - .vectors 0xffff0000 : AT(__vectors_start) { - *(.vectors) + OVERLAY 0xffff0000 : NOCROSSREFS AT(__vectors_lma) { + .vectors { + *(.vectors) + } + .vectors.bhb.loop8 { + *(.vectors.bhb.loop8) + } + .vectors.bhb.bpiall { + *(.vectors.bhb.bpiall) + } } ARM_LMA(__vectors, .vectors); - . =3D __vectors_lma + SIZEOF(.vectors); + ARM_LMA(__vectors_bhb_loop8, .vectors.bhb.loop8); + ARM_LMA(__vectors_bhb_bpiall, .vectors.bhb.bpiall); + . =3D __vectors_lma + SIZEOF(.vectors) + + SIZEOF(.vectors.bhb.loop8) + + SIZEOF(.vectors.bhb.bpiall); =20 __stubs_lma =3D .; .stubs ADDR(.vectors) + 0x1000 : AT(__stubs_lma) { --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -824,6 +824,16 @@ config HARDEN_BRANCH_PREDICTOR =20 If unsure, say Y. =20 +config HARDEN_BRANCH_HISTORY + bool "Harden Spectre style attacks against branch history" if EXPERT + depends on CPU_SPECTRE + default y + help + Speculation attacks against some high-performance processors can + make use of branch history to influence future speculation. When + taking an exception, a sequence of branches overwrites the branch + history, or branch history is invalidated. + config TLS_REG_EMUL bool select NEED_KUSER_HELPERS --- a/arch/arm/mm/proc-v7-bugs.c +++ b/arch/arm/mm/proc-v7-bugs.c @@ -186,6 +186,81 @@ static void cpu_v7_spectre_v2_init(void) spectre_v2_update_state(state, method); } =20 +#ifdef CONFIG_HARDEN_BRANCH_HISTORY +static int spectre_bhb_method; + +static const char *spectre_bhb_method_name(int method) +{ + switch (method) { + case SPECTRE_V2_METHOD_LOOP8: + return "loop"; + + case SPECTRE_V2_METHOD_BPIALL: + return "BPIALL"; + + default: + return "unknown"; + } +} + +static int spectre_bhb_install_workaround(int method) +{ + if (spectre_bhb_method !=3D method) { + if (spectre_bhb_method) { + pr_err("CPU%u: Spectre BHB: method disagreement, system vulnerable\n", + smp_processor_id()); + + return SPECTRE_VULNERABLE; + } + + if (spectre_bhb_update_vectors(method) =3D=3D SPECTRE_VULNERABLE) + return SPECTRE_VULNERABLE; + + spectre_bhb_method =3D method; + } + + pr_info("CPU%u: Spectre BHB: using %s workaround\n", + smp_processor_id(), spectre_bhb_method_name(method)); + + return SPECTRE_MITIGATED; +} +#else +static int spectre_bhb_install_workaround(int method) +{ + return SPECTRE_VULNERABLE; +} +#endif + +static void cpu_v7_spectre_bhb_init(void) +{ + unsigned int state, method =3D 0; + + switch (read_cpuid_part()) { + case ARM_CPU_PART_CORTEX_A15: + case ARM_CPU_PART_BRAHMA_B15: + case ARM_CPU_PART_CORTEX_A57: + case ARM_CPU_PART_CORTEX_A72: + state =3D SPECTRE_MITIGATED; + method =3D SPECTRE_V2_METHOD_LOOP8; + break; + + case ARM_CPU_PART_CORTEX_A73: + case ARM_CPU_PART_CORTEX_A75: + state =3D SPECTRE_MITIGATED; + method =3D SPECTRE_V2_METHOD_BPIALL; + break; + + default: + state =3D SPECTRE_UNAFFECTED; + break; + } + + if (state =3D=3D SPECTRE_MITIGATED) + state =3D spectre_bhb_install_workaround(method); + + spectre_v2_update_state(state, method); +} + static __maybe_unused bool cpu_v7_check_auxcr_set(bool *warned, u32 mask, const char *msg) { @@ -226,4 +301,5 @@ void cpu_v7_ca15_ibe(void) void cpu_v7_bugs_init(void) { cpu_v7_spectre_v2_init(); + cpu_v7_spectre_bhb_init(); } From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5877C433EF for ; Thu, 10 Mar 2022 14:22:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232596AbiCJOXZ (ORCPT ); Thu, 10 Mar 2022 09:23:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244350AbiCJOTL (ORCPT ); Thu, 10 Mar 2022 09:19:11 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B220B8B52; Thu, 10 Mar 2022 06:16:07 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 486C261B63; Thu, 10 Mar 2022 14:16:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5707AC340E8; Thu, 10 Mar 2022 14:16:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921765; bh=YYTxn4Nwrg6CuOgCloYwoSlfT43YKOmCi0fRD30gcL8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wTnznO68SjKNfoXctdLF0OdNFUJ41sRjENk7V4uKvgAtOwC3tjX39vnk+7Hm21OpE SLDYTWZjcmHvnxFjS+uXcnFnvlu+pp/IDmE7HKaxPzq22bfXZXgFqTo8ZIpYtxy9qS 2wGv2wa/xu6U5kbIbUvnIiVLLQKoMDd/zLNIlckM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Russell King (Oracle)" Subject: [PATCH 4.9 23/38] ARM: include unprivileged BPF status in Spectre V2 reporting Date: Thu, 10 Mar 2022 15:13:36 +0100 Message-Id: <20220310140808.814428235@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Russell King (Oracle) commit 25875aa71dfefd1959f07e626c4d285b88b27ac2 upstream. The mitigations for Spectre-BHB are only applied when an exception is taken, but when unprivileged BPF is enabled, userspace can load BPF programs that can be used to exploit the problem. When unprivileged BPF is enabled, report the vulnerable status via the spectre_v2 sysfs file. Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/arm/kernel/spectre.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/arch/arm/kernel/spectre.c +++ b/arch/arm/kernel/spectre.c @@ -1,9 +1,19 @@ // SPDX-License-Identifier: GPL-2.0-only +#include #include #include =20 #include =20 +static bool _unprivileged_ebpf_enabled(void) +{ +#ifdef CONFIG_BPF_SYSCALL + return !sysctl_unprivileged_bpf_disabled; +#else + return false +#endif +} + ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *a= ttr, char *buf) { @@ -31,6 +41,9 @@ ssize_t cpu_show_spectre_v2(struct devic if (spectre_v2_state !=3D SPECTRE_MITIGATED) return sprintf(buf, "%s\n", "Vulnerable"); =20 + if (_unprivileged_ebpf_enabled()) + return sprintf(buf, "Vulnerable: Unprivileged eBPF enabled\n"); + switch (spectre_v2_methods) { case SPECTRE_V2_METHOD_BPIALL: method =3D "Branch predictor hardening"; From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A4CFC4321E for ; Thu, 10 Mar 2022 14:22:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243662AbiCJOXJ (ORCPT ); Thu, 10 Mar 2022 09:23:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244298AbiCJOTI (ORCPT ); Thu, 10 Mar 2022 09:19:08 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1314171EC1; Thu, 10 Mar 2022 06:15:59 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id ECB12B825F3; Thu, 10 Mar 2022 14:15:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C606C36AE9; Thu, 10 Mar 2022 14:15:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921721; bh=dBM59trElM9mKdvh5X3TAf3lhidiLDUO/YzmBUoNg2U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Slh6n6Hb9bPYmCPeeui/wA1WVpnzrb1KxFFoXihgKXTIRT5yLrPWkQoV2JXE6BI2b zcF0GHTA6Pe4SwRCIugxCmyitT2raUkN9kOUDTlTs3n3KpkRiKuLICkffynVwSvjk7 TG51NPL6B1DXCl3pf+mHMdqLuNz4xhXdrXRvRw8Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Emmanuel Gil Peyrot , Nathan Chancellor , Linus Torvalds Subject: [PATCH 4.9 24/38] ARM: fix build error when BPF_SYSCALL is disabled Date: Thu, 10 Mar 2022 15:13:37 +0100 Message-Id: <20220310140808.843512853@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Emmanuel Gil Peyrot commit 330f4c53d3c2d8b11d86ec03a964b86dc81452f5 upstream. It was missing a semicolon. Signed-off-by: Emmanuel Gil Peyrot Reviewed-by: Nathan Chancellor Fixes: 25875aa71dfe ("ARM: include unprivileged BPF status in Spectre V2 re= porting"). Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/arm/kernel/spectre.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/kernel/spectre.c +++ b/arch/arm/kernel/spectre.c @@ -10,7 +10,7 @@ static bool _unprivileged_ebpf_enabled(v #ifdef CONFIG_BPF_SYSCALL return !sysctl_unprivileged_bpf_disabled; #else - return false + return false; #endif } From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E82CC433EF for ; Thu, 10 Mar 2022 14:24:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243656AbiCJOZL (ORCPT ); Thu, 10 Mar 2022 09:25:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244439AbiCJOTV (ORCPT ); Thu, 10 Mar 2022 09:19:21 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8574BF528; Thu, 10 Mar 2022 06:16:18 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3266461C7A; Thu, 10 Mar 2022 14:15:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21DD8C340E8; Thu, 10 Mar 2022 14:15:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921742; bh=lhCYm36lISKlmiaC/3uFiBZIuFSVw3qpMR4feD6Xf4o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MmVb+wN6BI7RGxI3c5gUffkcNdgrGKZMpa2rTRwkFKIqpcH2DZbES7w1pxxDdJPRA DkUkxF0C8n4+vtjseciPyPwsn4sjQIJjL/NLZe4O35QwTx1OkvxTnGZcUTnO/R8ms3 UsNsf7JnVDfmpb3ta5lEOUCirOjaKpGvZejEzz68= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, kernel test robot , "Russell King (Oracle)" , Catalin Marinas , Linus Torvalds Subject: [PATCH 4.9 25/38] ARM: fix co-processor register typo Date: Thu, 10 Mar 2022 15:13:38 +0100 Message-Id: <20220310140808.872936077@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Russell King (Oracle) commit 33970b031dc4653cc9dc80f2886976706c4c8ef1 upstream. In the recent Spectre BHB patches, there was a typo that is only exposed in certain configurations: mcr p15,0,XX,c7,r5,4 should have been mcr p15,0,XX,c7,c5,4 Reported-by: kernel test robot Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround") Signed-off-by: Russell King (Oracle) Acked-by: Catalin Marinas Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/arm/include/asm/assembler.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -114,7 +114,7 @@ .endm =20 .macro isb, args - mcr p15, 0, r0, c7, r5, 4 + mcr p15, 0, r0, c7, c5, 4 .endm #endif From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 080EBC433F5 for ; Thu, 10 Mar 2022 14:24:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243703AbiCJOY7 (ORCPT ); Thu, 10 Mar 2022 09:24:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244250AbiCJOTE (ORCPT ); Thu, 10 Mar 2022 09:19:04 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1D701704C0; Thu, 10 Mar 2022 06:15:51 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AE99BB8267B; Thu, 10 Mar 2022 14:15:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18E7FC340E8; Thu, 10 Mar 2022 14:15:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921745; bh=DzqVsiVDsID/SYy4BDD6YW+JEMYUAwX1RdJngJSgkrg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vw8EAkukNP7W1k477R9qRdwOJtICzzwIgaEXbP1rTpw4aHeN+6EvrL7HQkwNSW/KF 6JdCW+KRUyL2+WlmD792o19i/2q30pTqMboOo0AWWP0R1X7cx79rmxCaSZ+anvQ595 QccIM6sI+b9tNiywf4v+skSZ9KeUwcg4HUgpIPX4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nathan Chancellor , Linus Torvalds Subject: [PATCH 4.9 26/38] ARM: Do not use NOCROSSREFS directive with ld.lld Date: Thu, 10 Mar 2022 15:13:39 +0100 Message-Id: <20220310140808.900651068@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Nathan Chancellor commit 36168e387fa7d0f1fe0cd5cf76c8cea7aee714fa upstream. ld.lld does not support the NOCROSSREFS directive at the moment, which breaks the build after commit b9baf5c8c5c3 ("ARM: Spectre-BHB workaround"): ld.lld: error: ./arch/arm/kernel/vmlinux.lds:34: AT expected, but got NOC= ROSSREFS Support for this directive will eventually be implemented, at which point a version check can be added. To avoid breaking the build in the meantime, just define NOCROSSREFS to nothing when using ld.lld, with a link to the issue for tracking. Cc: stable@vger.kernel.org Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround") Link: https://github.com/ClangBuiltLinux/linux/issues/1609 Signed-off-by: Nathan Chancellor Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/arm/kernel/vmlinux-xip.lds.S | 8 ++++++++ arch/arm/kernel/vmlinux.lds.S | 8 ++++++++ 2 files changed, 16 insertions(+) --- a/arch/arm/kernel/vmlinux-xip.lds.S +++ b/arch/arm/kernel/vmlinux-xip.lds.S @@ -12,6 +12,14 @@ #include #include =20 +/* + * ld.lld does not support NOCROSSREFS: + * https://github.com/ClangBuiltLinux/linux/issues/1609 + */ +#ifdef CONFIG_LD_IS_LLD +#define NOCROSSREFS +#endif + /* Set start/end symbol names to the LMA for the section */ #define ARM_LMA(sym, section) \ sym##_start =3D LOADADDR(section); \ --- a/arch/arm/kernel/vmlinux.lds.S +++ b/arch/arm/kernel/vmlinux.lds.S @@ -14,6 +14,14 @@ #include #include =20 +/* + * ld.lld does not support NOCROSSREFS: + * https://github.com/ClangBuiltLinux/linux/issues/1609 + */ +#ifdef CONFIG_LD_IS_LLD +#define NOCROSSREFS +#endif + /* Set start/end symbol names to the LMA for the section */ #define ARM_LMA(sym, section) \ sym##_start =3D LOADADDR(section); \ From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2179FC433F5 for ; Thu, 10 Mar 2022 14:22:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243439AbiCJOXu (ORCPT ); Thu, 10 Mar 2022 09:23:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244472AbiCJOTY (ORCPT ); Thu, 10 Mar 2022 09:19:24 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 34BB1C1CBF; Thu, 10 Mar 2022 06:16:22 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BDB5CB82676; Thu, 10 Mar 2022 14:15:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C607FC340EB; Thu, 10 Mar 2022 14:15:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921748; bh=DvEI6aRgVGSp13qeZIvZaOfCgzZ25LrHDBt0QKYNd0k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iTU4MddBPFYOTzKHtSSh7tvmjaa95J9H0E1cYUvTussJZkGPp49zF++eGM4io5ySK C/5vNe3K0tUvY8NfK2+RO+oYBaUQ+DkOwRaN98YlEcwpkJlD7T9JHysMZGFeBreDRS S70RR7Ml1B3rIRxpfxEM86xOsHVf/RwCPmFlWTUQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Meelis Roos , Masahiro Yamada , Zhenzhong Duan , Borislav Petkov , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Ben Hutchings Subject: [PATCH 4.9 27/38] x86/build: Fix compiler support check for CONFIG_RETPOLINE Date: Thu, 10 Mar 2022 15:13:40 +0100 Message-Id: <20220310140808.928982540@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Masahiro Yamada commit 25896d073d8a0403b07e6dec56f58e6c33678207 upstream. It is troublesome to add a diagnostic like this to the Makefile parse stage because the top-level Makefile could be parsed with a stale include/config/auto.conf. Once you are hit by the error about non-retpoline compiler, the compilation still breaks even after disabling CONFIG_RETPOLINE. The easiest fix is to move this check to the "archprepare" like this commit did: 829fe4aa9ac1 ("x86: Allow generating user-space headers without a compile= r") Reported-by: Meelis Roos Tested-by: Meelis Roos Signed-off-by: Masahiro Yamada Acked-by: Zhenzhong Duan Cc: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Zhenzhong Duan Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compil= er support") Link: http://lkml.kernel.org/r/1543991239-18476-1-git-send-email-yamada.mas= ahiro@socionext.com Link: https://lkml.org/lkml/2018/12/4/206 Signed-off-by: Ingo Molnar [bwh: Backported to 4.9: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/Makefile | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -221,9 +221,6 @@ ifdef CONFIG_RETPOLINE RETPOLINE_CFLAGS_CLANG :=3D -mretpoline-external-thunk =20 RETPOLINE_CFLAGS +=3D $(call cc-option,$(RETPOLINE_CFLAGS_GCC),$(call = cc-option,$(RETPOLINE_CFLAGS_CLANG))) - ifeq ($(RETPOLINE_CFLAGS),) - $(error You are building kernel with non-retpoline compiler, please = update your compiler.) - endif KBUILD_CFLAGS +=3D $(RETPOLINE_CFLAGS) endif =20 @@ -240,6 +237,13 @@ archprepare: ifeq ($(CONFIG_KEXEC_FILE),y) $(Q)$(MAKE) $(build)=3Darch/x86/purgatory arch/x86/purgatory/kexec-purgat= ory.c endif +ifdef CONFIG_RETPOLINE +ifeq ($(RETPOLINE_CFLAGS),) + @echo "You are building kernel with non-retpoline compiler." >&2 + @echo "Please update your compiler." >&2 + @false +endif +endif =20 ### # Kernel objects From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 69B94C43217 for ; Thu, 10 Mar 2022 14:22:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243553AbiCJOXD (ORCPT ); Thu, 10 Mar 2022 09:23:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244256AbiCJOTE (ORCPT ); Thu, 10 Mar 2022 09:19:04 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2AC1A1704D0; Thu, 10 Mar 2022 06:15:52 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 024F261C67; Thu, 10 Mar 2022 14:15:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD90BC36AF5; Thu, 10 Mar 2022 14:15:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921751; bh=TulCEYJwDG+ZNjCzCFBRTe+9gAE+iWf3pD+bnXcqBTc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hwTMYIL2V+H90wccEOYxrBMcRZnGxlIHaFzL0vKJ7FzQqic4IW2ROFFIC0UCtZVRN jJe+qvSAFDNSMgj2c3dqIGEMVz6KCjjllM15RKatXC0KjmWwj2sCT+tR88VJDqlXhG +/rgiKT5JTBZvS8TCHYvsAI/YhgAzWALxwG8n+hI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, WANG Chao , Borislav Petkov , Zhenzhong Duan , Masahiro Yamada , "H. Peter Anvin" , Andi Kleen , Andrew Morton , Andy Lutomirski , Arnd Bergmann , Daniel Borkmann , David Woodhouse , Geert Uytterhoeven , Jessica Yu , Jiri Kosina , Kees Cook , Konrad Rzeszutek Wilk , Luc Van Oostenryck , Michal Marek , Miguel Ojeda , Peter Zijlstra , Tim Chen , Vasily Gorbik , linux-kbuild@vger.kernel.org, srinivas.eeda@oracle.com, x86-ml , Ben Hutchings Subject: [PATCH 4.9 28/38] x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE Date: Thu, 10 Mar 2022 15:13:41 +0100 Message-Id: <20220310140808.958165558@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: WANG Chao commit e4f358916d528d479c3c12bd2fd03f2d5a576380 upstream. Commit 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler su= pport") replaced the RETPOLINE define with CONFIG_RETPOLINE checks. Remove the remaining pieces. [ bp: Massage commit message. ] Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compil= er support") Signed-off-by: WANG Chao Signed-off-by: Borislav Petkov Reviewed-by: Zhenzhong Duan Reviewed-by: Masahiro Yamada Cc: "H. Peter Anvin" Cc: Andi Kleen Cc: Andrew Morton Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Daniel Borkmann Cc: David Woodhouse Cc: Geert Uytterhoeven Cc: Jessica Yu Cc: Jiri Kosina Cc: Kees Cook Cc: Konrad Rzeszutek Wilk Cc: Luc Van Oostenryck Cc: Michal Marek Cc: Miguel Ojeda Cc: Peter Zijlstra Cc: Tim Chen Cc: Vasily Gorbik Cc: linux-kbuild@vger.kernel.org Cc: srinivas.eeda@oracle.com Cc: stable Cc: x86-ml Link: https://lkml.kernel.org/r/20181210163725.95977-1-chao.wang@ucloud.cn [bwh: Backported to 4.9: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/kernel/cpu/bugs.c | 2 +- include/linux/compiler-gcc.h | 2 +- include/linux/module.h | 2 +- scripts/mod/modpost.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -586,7 +586,7 @@ static enum spectre_v2_user_mitigation s static enum spectre_v2_user_mitigation spectre_v2_user_ibpb __ro_after_ini= t =3D SPECTRE_V2_USER_NONE; =20 -#ifdef RETPOLINE +#ifdef CONFIG_RETPOLINE static bool spectre_v2_bad_module; =20 bool retpoline_module_ok(bool has_retpoline) --- a/include/linux/compiler-gcc.h +++ b/include/linux/compiler-gcc.h @@ -107,7 +107,7 @@ #define __weak __attribute__((weak)) #define __alias(symbol) __attribute__((alias(#symbol))) =20 -#ifdef RETPOLINE +#ifdef CONFIG_RETPOLINE #define __noretpoline __attribute__((indirect_branch("keep"))) #endif =20 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -791,7 +791,7 @@ static inline void module_bug_finalize(c static inline void module_bug_cleanup(struct module *mod) {} #endif /* CONFIG_GENERIC_BUG */ =20 -#ifdef RETPOLINE +#ifdef CONFIG_RETPOLINE extern bool retpoline_module_ok(bool has_retpoline); #else static inline bool retpoline_module_ok(bool has_retpoline) --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -2147,7 +2147,7 @@ static void add_intree_flag(struct buffe /* Cannot check for assembler */ static void add_retpoline(struct buffer *b) { - buf_printf(b, "\n#ifdef RETPOLINE\n"); + buf_printf(b, "\n#ifdef CONFIG_RETPOLINE\n"); buf_printf(b, "MODULE_INFO(retpoline, \"Y\");\n"); buf_printf(b, "#endif\n"); } From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D6DDC433EF for ; Thu, 10 Mar 2022 14:24:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243762AbiCJOZH (ORCPT ); Thu, 10 Mar 2022 09:25:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244302AbiCJOTI (ORCPT ); Thu, 10 Mar 2022 09:19:08 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66337171EDA; Thu, 10 Mar 2022 06:16:00 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 98A8EB81E9E; Thu, 10 Mar 2022 14:15:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE2BEC340E8; Thu, 10 Mar 2022 14:15:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921754; bh=xj+QdKUrjDDFGwApWZ1l3iJAR6528yj7oSQnmuWft5c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GLGxLjopEFEkDWPek2ty4KR0yS41CUhigDAgmaJnFEAwlwArBcgkQUz9GX3LPq674 FKy/iXh96ekafe8L0xNnf8XUKZsHrKHsR3cELd4Jwt1U17eBcveIuX3hsl0iiATZDj duKtTKgDhLds8doVD+rMJKT0vDg6wRFEK0CpFEHQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, kernel test robot , "Russell King (Oracle)" , Linus Torvalds Subject: [PATCH 4.9 29/38] ARM: fix build warning in proc-v7-bugs.c Date: Thu, 10 Mar 2022 15:13:42 +0100 Message-Id: <20220310140808.987050659@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Russell King (Oracle) commit b1a384d2cbccb1eb3f84765020d25e2c1929706e upstream. The kernel test robot discovered that building without HARDEN_BRANCH_PREDICTOR issues a warning due to a missing argument to pr_info(). Add the missing argument. Reported-by: kernel test robot Fixes: 9dd78194a372 ("ARM: report Spectre v2 status through sysfs") Signed-off-by: Russell King (Oracle) Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/arm/mm/proc-v7-bugs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/arm/mm/proc-v7-bugs.c +++ b/arch/arm/mm/proc-v7-bugs.c @@ -110,7 +110,8 @@ static unsigned int spectre_v2_install_w #else static unsigned int spectre_v2_install_workaround(unsigned int method) { - pr_info("CPU%u: Spectre V2: workarounds disabled by configuration\n"); + pr_info("CPU%u: Spectre V2: workarounds disabled by configuration\n", + smp_processor_id()); =20 return SPECTRE_VULNERABLE; } From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9AC32C4167E for ; Thu, 10 Mar 2022 14:22:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243723AbiCJOXM (ORCPT ); Thu, 10 Mar 2022 09:23:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244316AbiCJOTI (ORCPT ); Thu, 10 Mar 2022 09:19:08 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 378BD17227C; Thu, 10 Mar 2022 06:16:03 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BC0D9B8267E; Thu, 10 Mar 2022 14:15:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2136C340EB; Thu, 10 Mar 2022 14:15:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921757; bh=CDnXzzZJMtnbimerPsJ8oEfsOtNph0fXQEXJDIJdPnQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xz3kzhiB8PowkcR8WUdgCl/bQNGBkdmfw1n6y7xL6JX2c9T4VnapyGM7DHqXwGei2 SRQcYU7NgbBKRnkK48NVJ80XVEWSx68mUR5Zsyz7IDV9ft7vz06gkRtRNcUN2ebMXa HvDffPGGawwVRZxlZHXdDV3+mdsndbFCI/gfNNdI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Demi Marie Obenour , Juergen Gross , Jan Beulich Subject: [PATCH 4.9 30/38] xen/xenbus: dont let xenbus_grant_ring() remove grants in error case Date: Thu, 10 Mar 2022 15:13:43 +0100 Message-Id: <20220310140809.016459163@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Juergen Gross Commit 3777ea7bac3113005b7180e6b9dadf16d19a5827 upstream. Letting xenbus_grant_ring() tear down grants in the error case is problematic, as the other side could already have used these grants. Calling gnttab_end_foreign_access_ref() without checking success is resulting in an unclear situation for any caller of xenbus_grant_ring() as in the error case the memory pages of the ring page might be partially mapped. Freeing them would risk unwanted foreign access to them, while not freeing them would leak memory. In order to remove the need to undo any gnttab_grant_foreign_access() calls, use gnttab_alloc_grant_references() to make sure no further error can occur in the loop granting access to the ring pages. It should be noted that this way of handling removes leaking of grant entries in the error case, too. This is CVE-2022-23040 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- drivers/xen/xenbus/xenbus_client.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) --- a/drivers/xen/xenbus/xenbus_client.c +++ b/drivers/xen/xenbus/xenbus_client.c @@ -387,7 +387,14 @@ int xenbus_grant_ring(struct xenbus_devi unsigned int nr_pages, grant_ref_t *grefs) { int err; - int i, j; + unsigned int i; + grant_ref_t gref_head; + + err =3D gnttab_alloc_grant_references(nr_pages, &gref_head); + if (err) { + xenbus_dev_fatal(dev, err, "granting access to ring page"); + return err; + } =20 for (i =3D 0; i < nr_pages; i++) { unsigned long gfn; @@ -397,23 +404,14 @@ int xenbus_grant_ring(struct xenbus_devi else gfn =3D virt_to_gfn(vaddr); =20 - err =3D gnttab_grant_foreign_access(dev->otherend_id, gfn, 0); - if (err < 0) { - xenbus_dev_fatal(dev, err, - "granting access to ring page"); - goto fail; - } - grefs[i] =3D err; + grefs[i] =3D gnttab_claim_grant_reference(&gref_head); + gnttab_grant_foreign_access_ref(grefs[i], dev->otherend_id, + gfn, 0); =20 vaddr =3D vaddr + XEN_PAGE_SIZE; } =20 return 0; - -fail: - for (j =3D 0; j < i; j++) - gnttab_end_foreign_access_ref(grefs[j], 0); - return err; } EXPORT_SYMBOL_GPL(xenbus_grant_ring); From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 582CFC433F5 for ; Thu, 10 Mar 2022 14:24:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243404AbiCJOZC (ORCPT ); Thu, 10 Mar 2022 09:25:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244322AbiCJOTJ (ORCPT ); Thu, 10 Mar 2022 09:19:09 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB0C6172888; Thu, 10 Mar 2022 06:16:03 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D0C5661C39; Thu, 10 Mar 2022 14:16:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA7CCC340E8; Thu, 10 Mar 2022 14:15:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921760; bh=tIRJjRTSlbPh8kjeK5uRXo4H5ulTD8w7NIMSEQd1/4M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rM5eZslWnLbHGCR2nRmXY1rxKTdTenjL2H6uZ5aG3tsSwJFX1e9vsbfIYWp11wosN 85y7VtgOz2/sDkNTkjxTBOVlx6qjiDVy/e8fMMaT8XO7H3yt95kBw7LHw+W/s0QB4Y kOlJsyKVv7vmwuzQeo11RkbheZXopsV9xq4rsQDc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Demi Marie Obenour , Juergen Gross , Jan Beulich Subject: [PATCH 4.9 31/38] xen/grant-table: add gnttab_try_end_foreign_access() Date: Thu, 10 Mar 2022 15:13:44 +0100 Message-Id: <20220310140809.044695427@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Juergen Gross Commit 6b1775f26a2da2b05a6dc8ec2b5d14e9a4701a1a upstream. Add a new grant table function gnttab_try_end_foreign_access(), which will remove and free a grant if it is not in use. Its main use case is to either free a grant if it is no longer in use, or to take some other action if it is still in use. This other action can be an error exit, or (e.g. in the case of blkfront persistent grant feature) some special handling. This is CVE-2022-23036, CVE-2022-23038 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- drivers/xen/grant-table.c | 14 ++++++++++++-- include/xen/grant_table.h | 12 ++++++++++++ 2 files changed, 24 insertions(+), 2 deletions(-) --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -377,11 +377,21 @@ static void gnttab_add_deferred(grant_re what, ref, page ? page_to_pfn(page) : -1); } =20 +int gnttab_try_end_foreign_access(grant_ref_t ref) +{ + int ret =3D _gnttab_end_foreign_access_ref(ref, 0); + + if (ret) + put_free_entry(ref); + + return ret; +} +EXPORT_SYMBOL_GPL(gnttab_try_end_foreign_access); + void gnttab_end_foreign_access(grant_ref_t ref, int readonly, unsigned long page) { - if (gnttab_end_foreign_access_ref(ref, readonly)) { - put_free_entry(ref); + if (gnttab_try_end_foreign_access(ref)) { if (page !=3D 0) put_page(virt_to_page(page)); } else --- a/include/xen/grant_table.h +++ b/include/xen/grant_table.h @@ -97,10 +97,22 @@ int gnttab_end_foreign_access_ref(grant_ * access has been ended, free the given page too. Access will be ended * immediately iff the grant entry is not in use, otherwise it will happen * some time later. page may be 0, in which case no freeing will occur. + * Note that the granted page might still be accessed (read or write) by t= he + * other side after gnttab_end_foreign_access() returns, so even if page w= as + * specified as 0 it is not allowed to just reuse the page for other + * purposes immediately. */ void gnttab_end_foreign_access(grant_ref_t ref, int readonly, unsigned long page); =20 +/* + * End access through the given grant reference, iff the grant entry is + * no longer in use. In case of success ending foreign access, the + * grant reference is deallocated. + * Return 1 if the grant entry was freed, 0 if it is still in use. + */ +int gnttab_try_end_foreign_access(grant_ref_t ref); + int gnttab_grant_foreign_transfer(domid_t domid, unsigned long pfn); =20 unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref); From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7541CC433F5 for ; Thu, 10 Mar 2022 14:23:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243476AbiCJOYE (ORCPT ); Thu, 10 Mar 2022 09:24:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43328 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244556AbiCJOTk (ORCPT ); Thu, 10 Mar 2022 09:19:40 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 31E6B13A1C5; Thu, 10 Mar 2022 06:16:30 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 26789B82615; Thu, 10 Mar 2022 14:16:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96BB0C340E8; Thu, 10 Mar 2022 14:16:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921763; bh=QvXUabqW2e72/S9y0yAqLS0m5Evxyk8ez5ZxAIHm2YE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gWWPs8o+KJyW2VxWrf4TWQr0dbfacY1ynEci/RAy3tPaHsWg5dqnTI0OMuwOLwB9Y NdLtV+qd5gG5FHAl+uHs52GvXZc7g6W0rQRJJi+1y8lhHFzkR926N17E3T0zuvrlWv /JVlGW4jJNyYqGa/qy66HARh+t7UDsk7kZkdg6o4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Demi Marie Obenour , Juergen Gross , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH 4.9 32/38] xen/blkfront: dont use gnttab_query_foreign_access() for mapped status Date: Thu, 10 Mar 2022 15:13:45 +0100 Message-Id: <20220310140809.073321234@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Juergen Gross Commit abf1fd5919d6238ee3bc5eb4a9b6c3947caa6638 upstream. It isn't enough to check whether a grant is still being in use by calling gnttab_query_foreign_access(), as a mapping could be realized by the other side just after having called that function. In case the call was done in preparation of revoking a grant it is better to do so via gnttab_end_foreign_access_ref() and check the success of that operation instead. For the ring allocation use alloc_pages_exact() in order to avoid high order pages in case of a multi-page ring. If a grant wasn't unmapped by the backend without persistent grants being used, set the device state to "error". This is CVE-2022-23036 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Roger Pau Monn=C3=A9 Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- drivers/block/xen-blkfront.c | 67 +++++++++++++++++++++++++-------------= ----- 1 file changed, 39 insertions(+), 28 deletions(-) --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1266,17 +1266,16 @@ static void blkif_free_ring(struct blkfr list_for_each_entry_safe(persistent_gnt, n, &rinfo->grants, node) { list_del(&persistent_gnt->node); - if (persistent_gnt->gref !=3D GRANT_INVALID_REF) { - gnttab_end_foreign_access(persistent_gnt->gref, - 0, 0UL); - rinfo->persistent_gnts_c--; - } + if (persistent_gnt->gref =3D=3D GRANT_INVALID_REF || + !gnttab_try_end_foreign_access(persistent_gnt->gref)) + continue; + + rinfo->persistent_gnts_c--; if (info->feature_persistent) __free_page(persistent_gnt->page); kfree(persistent_gnt); } } - BUG_ON(rinfo->persistent_gnts_c !=3D 0); =20 for (i =3D 0; i < BLK_RING_SIZE(info); i++) { /* @@ -1333,7 +1332,8 @@ free_shadow: rinfo->ring_ref[i] =3D GRANT_INVALID_REF; } } - free_pages((unsigned long)rinfo->ring.sring, get_order(info->nr_ring_page= s * XEN_PAGE_SIZE)); + free_pages_exact(rinfo->ring.sring, + info->nr_ring_pages * XEN_PAGE_SIZE); rinfo->ring.sring =3D NULL; =20 if (rinfo->irq) @@ -1417,9 +1417,15 @@ static int blkif_get_final_status(enum b return BLKIF_RSP_OKAY; } =20 -static bool blkif_completion(unsigned long *id, - struct blkfront_ring_info *rinfo, - struct blkif_response *bret) +/* + * Return values: + * 1 response processed. + * 0 missing further responses. + * -1 error while processing. + */ +static int blkif_completion(unsigned long *id, + struct blkfront_ring_info *rinfo, + struct blkif_response *bret) { int i =3D 0; struct scatterlist *sg; @@ -1493,42 +1499,43 @@ static bool blkif_completion(unsigned lo } /* Add the persistent grant into the list of free grants */ for (i =3D 0; i < num_grant; i++) { - if (gnttab_query_foreign_access(s->grants_used[i]->gref)) { + if (!gnttab_try_end_foreign_access(s->grants_used[i]->gref)) { /* * If the grant is still mapped by the backend (the * backend has chosen to make this grant persistent) * we add it at the head of the list, so it will be * reused first. */ - if (!info->feature_persistent) - pr_alert_ratelimited("backed has not unmapped grant: %u\n", - s->grants_used[i]->gref); + if (!info->feature_persistent) { + pr_alert("backed has not unmapped grant: %u\n", + s->grants_used[i]->gref); + return -1; + } list_add(&s->grants_used[i]->node, &rinfo->grants); rinfo->persistent_gnts_c++; } else { /* - * If the grant is not mapped by the backend we end the - * foreign access and add it to the tail of the list, - * so it will not be picked again unless we run out of - * persistent grants. + * If the grant is not mapped by the backend we add it + * to the tail of the list, so it will not be picked + * again unless we run out of persistent grants. */ - gnttab_end_foreign_access(s->grants_used[i]->gref, 0, 0UL); s->grants_used[i]->gref =3D GRANT_INVALID_REF; list_add_tail(&s->grants_used[i]->node, &rinfo->grants); } } if (s->req.operation =3D=3D BLKIF_OP_INDIRECT) { for (i =3D 0; i < INDIRECT_GREFS(num_grant); i++) { - if (gnttab_query_foreign_access(s->indirect_grants[i]->gref)) { - if (!info->feature_persistent) - pr_alert_ratelimited("backed has not unmapped grant: %u\n", - s->indirect_grants[i]->gref); + if (!gnttab_try_end_foreign_access(s->indirect_grants[i]->gref)) { + if (!info->feature_persistent) { + pr_alert("backed has not unmapped grant: %u\n", + s->indirect_grants[i]->gref); + return -1; + } list_add(&s->indirect_grants[i]->node, &rinfo->grants); rinfo->persistent_gnts_c++; } else { struct page *indirect_page; =20 - gnttab_end_foreign_access(s->indirect_grants[i]->gref, 0, 0UL); /* * Add the used indirect page back to the list of * available pages for indirect grefs. @@ -1610,12 +1617,17 @@ static irqreturn_t blkif_interrupt(int i } =20 if (bret.operation !=3D BLKIF_OP_DISCARD) { + int ret; + /* * We may need to wait for an extra response if the * I/O request is split in 2 */ - if (!blkif_completion(&id, rinfo, &bret)) + ret =3D blkif_completion(&id, rinfo, &bret); + if (!ret) continue; + if (unlikely(ret < 0)) + goto err; } =20 if (add_id_to_freelist(rinfo, id)) { @@ -1717,8 +1729,7 @@ static int setup_blkring(struct xenbus_d for (i =3D 0; i < info->nr_ring_pages; i++) rinfo->ring_ref[i] =3D GRANT_INVALID_REF; =20 - sring =3D (struct blkif_sring *)__get_free_pages(GFP_NOIO | __GFP_HIGH, - get_order(ring_size)); + sring =3D alloc_pages_exact(ring_size, GFP_NOIO); if (!sring) { xenbus_dev_fatal(dev, -ENOMEM, "allocating shared ring"); return -ENOMEM; @@ -1728,7 +1739,7 @@ static int setup_blkring(struct xenbus_d =20 err =3D xenbus_grant_ring(dev, rinfo->ring.sring, info->nr_ring_pages, gr= ef); if (err < 0) { - free_pages((unsigned long)sring, get_order(ring_size)); + free_pages_exact(sring, ring_size); rinfo->ring.sring =3D NULL; goto fail; } From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F50EC433FE for ; Thu, 10 Mar 2022 14:22:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241984AbiCJOXc (ORCPT ); Thu, 10 Mar 2022 09:23:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244056AbiCJOSn (ORCPT ); Thu, 10 Mar 2022 09:18:43 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C18D169229; Thu, 10 Mar 2022 06:15:26 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id F2605B82615; Thu, 10 Mar 2022 14:15:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51E3AC340E8; Thu, 10 Mar 2022 14:15:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921724; bh=+jYMK9ccxxirlSlYIOACAJmyJoUQsDEEQvIaAWiLdJ4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vmyYVeelPUyRvRDCF8pEJejs9yTWRR9dDKwHUb+fISZQOSdFBj9nWnt/aY2c/aK8e dEO9TPnZBwOsc4kCwazobwz5bvS+uiBcgr5ai7xp3qkeedlrH1PjooM4AfC66ub1xA Y+B+HGdJvOLwKrHS9v+mbnqSrkI8qRvB04BSzzK8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Demi Marie Obenour , Juergen Gross , Jan Beulich Subject: [PATCH 4.9 33/38] xen/netfront: dont use gnttab_query_foreign_access() for mapped status Date: Thu, 10 Mar 2022 15:13:46 +0100 Message-Id: <20220310140809.101922402@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Juergen Gross Commit 31185df7e2b1d2fa1de4900247a12d7b9c7087eb upstream. It isn't enough to check whether a grant is still being in use by calling gnttab_query_foreign_access(), as a mapping could be realized by the other side just after having called that function. In case the call was done in preparation of revoking a grant it is better to do so via gnttab_end_foreign_access_ref() and check the success of that operation instead. This is CVE-2022-23037 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- drivers/net/xen-netfront.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -413,14 +413,12 @@ static bool xennet_tx_buf_gc(struct netf queue->tx_link[id] =3D TX_LINK_NONE; skb =3D queue->tx_skbs[id]; queue->tx_skbs[id] =3D NULL; - if (unlikely(gnttab_query_foreign_access( - queue->grant_tx_ref[id]) !=3D 0)) { + if (unlikely(!gnttab_end_foreign_access_ref( + queue->grant_tx_ref[id], GNTMAP_readonly))) { dev_alert(dev, "Grant still in use by backend domain\n"); goto err; } - gnttab_end_foreign_access_ref( - queue->grant_tx_ref[id], GNTMAP_readonly); gnttab_release_grant_reference( &queue->gref_tx_head, queue->grant_tx_ref[id]); queue->grant_tx_ref[id] =3D GRANT_INVALID_REF; From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C73E0C433FE for ; Thu, 10 Mar 2022 14:24:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243721AbiCJOZP (ORCPT ); Thu, 10 Mar 2022 09:25:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244620AbiCJOTo (ORCPT ); Thu, 10 Mar 2022 09:19:44 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 754E517775B; Thu, 10 Mar 2022 06:16:38 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D2474B825A7; Thu, 10 Mar 2022 14:15:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E3C3C340E8; Thu, 10 Mar 2022 14:15:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921727; bh=xEM7bM1MS3ZnvwOhutZQEBGhLFXWiu3krUw3+5mpfAA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kJ9W5+bn0p7yck8GMsz0pgg1KWz1zylVgFPVP3nQDw1XZMvRpJyB+wdRHcidjlRcE BRzSQCkKblQ1GYrwlXJHuuJkuDKrbB3loZqZhYm34Nx5bqtAtgV4HyH6oWwQK6Wh3d n8sGWz9QJTqTMA0txgf8eUW0Ffp1YceujFIo3UdM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Demi Marie Obenour , Juergen Gross , Jan Beulich Subject: [PATCH 4.9 34/38] xen/scsifront: dont use gnttab_query_foreign_access() for mapped status Date: Thu, 10 Mar 2022 15:13:47 +0100 Message-Id: <20220310140809.129519975@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Juergen Gross Commit 33172ab50a53578a95691310f49567c9266968b0 upstream. It isn't enough to check whether a grant is still being in use by calling gnttab_query_foreign_access(), as a mapping could be realized by the other side just after having called that function. In case the call was done in preparation of revoking a grant it is better to do so via gnttab_try_end_foreign_access() and check the success of that operation instead. This is CVE-2022-23038 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- drivers/scsi/xen-scsifront.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/scsi/xen-scsifront.c +++ b/drivers/scsi/xen-scsifront.c @@ -210,12 +210,11 @@ static void scsifront_gnttab_done(struct return; =20 for (i =3D 0; i < s->nr_grants; i++) { - if (unlikely(gnttab_query_foreign_access(s->gref[i]) !=3D 0)) { + if (unlikely(!gnttab_try_end_foreign_access(s->gref[i]))) { shost_printk(KERN_ALERT, info->host, KBUILD_MODNAME "grant still in use by backend\n"); BUG(); } - gnttab_end_foreign_access(s->gref[i], 0, 0UL); } =20 kfree(s->sg); From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0756C433F5 for ; Thu, 10 Mar 2022 14:23:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243685AbiCJOYw (ORCPT ); Thu, 10 Mar 2022 09:24:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244160AbiCJOS7 (ORCPT ); Thu, 10 Mar 2022 09:18:59 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A671B251A; Thu, 10 Mar 2022 06:15:39 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5BA2261C67; Thu, 10 Mar 2022 14:15:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5EFDDC340EB; Thu, 10 Mar 2022 14:15:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921730; bh=0SlhBY9FVbky4lNAtCvq+QSM2Rt7IiNUXbD6lBysKLc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UFdYgh6FsYyGQ7q7XfxNsSGATpZUv/rCFqabsEK7FGXO2merKw+w/O3ZXHFDFAEDZ aHhTa3QxPMH93gLRz/8YzcqWyEZjqjIeb7KpeZDfgl8cW4xiaDSOXt+dYfWW65lupV Alb7/h4JzYqaKX/+3p1XR6YxyG4H4+Ea+f+/qLbo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Demi Marie Obenour , Juergen Gross , Jan Beulich Subject: [PATCH 4.9 35/38] xen/gntalloc: dont use gnttab_query_foreign_access() Date: Thu, 10 Mar 2022 15:13:48 +0100 Message-Id: <20220310140809.157981695@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Juergen Gross Commit d3b6372c5881cb54925212abb62c521df8ba4809 upstream. Using gnttab_query_foreign_access() is unsafe, as it is racy by design. The use case in the gntalloc driver is not needed at all. While at it replace the call of gnttab_end_foreign_access_ref() with a call of gnttab_end_foreign_access(), which is what is really wanted there. In case the grant wasn't used due to an allocation failure, just free the grant via gnttab_free_grant_reference(). This is CVE-2022-23039 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- drivers/xen/gntalloc.c | 25 +++++++------------------ 1 file changed, 7 insertions(+), 18 deletions(-) --- a/drivers/xen/gntalloc.c +++ b/drivers/xen/gntalloc.c @@ -166,20 +166,14 @@ undo: __del_gref(gref); } =20 - /* It's possible for the target domain to map the just-allocated grant - * references by blindly guessing their IDs; if this is done, then - * __del_gref will leave them in the queue_gref list. They need to be - * added to the global list so that we can free them when they are no - * longer referenced. - */ - if (unlikely(!list_empty(&queue_gref))) - list_splice_tail(&queue_gref, &gref_list); mutex_unlock(&gref_mutex); return rc; } =20 static void __del_gref(struct gntalloc_gref *gref) { + unsigned long addr; + if (gref->notify.flags & UNMAP_NOTIFY_CLEAR_BYTE) { uint8_t *tmp =3D kmap(gref->page); tmp[gref->notify.pgoff] =3D 0; @@ -193,21 +187,16 @@ static void __del_gref(struct gntalloc_g gref->notify.flags =3D 0; =20 if (gref->gref_id) { - if (gnttab_query_foreign_access(gref->gref_id)) - return; - - if (!gnttab_end_foreign_access_ref(gref->gref_id, 0)) - return; - - gnttab_free_grant_reference(gref->gref_id); + if (gref->page) { + addr =3D (unsigned long)page_to_virt(gref->page); + gnttab_end_foreign_access(gref->gref_id, 0, addr); + } else + gnttab_free_grant_reference(gref->gref_id); } =20 gref_size--; list_del(&gref->next_gref); =20 - if (gref->page) - __free_page(gref->page); - kfree(gref); } From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E04AFC433FE for ; Thu, 10 Mar 2022 14:22:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243347AbiCJOXq (ORCPT ); Thu, 10 Mar 2022 09:23:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244420AbiCJOTT (ORCPT ); Thu, 10 Mar 2022 09:19:19 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB3A6BE1F9; Thu, 10 Mar 2022 06:16:15 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id DA757B82678; Thu, 10 Mar 2022 14:15:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D73FC340EB; Thu, 10 Mar 2022 14:15:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921733; bh=dq19W6oxUYyrbAuGknlft7AXPns9xdQ4oMNvwdExZjM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HbJiD64lEXkV8NkRIbgIPh4C0vzGTM1iIypzsqgpkC04S+s948Q52vOcQbEtOEFm5 RrxGjblFtsP9/YuwynB/h6u6yLCuZKrP4inenon33gM+J6iCVqDvUK2xZROjUNTcbH NAXvHv9eV2bql9YjRKb0s0bT09DO7ELH2R/8eFwQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Juergen Gross , Jan Beulich Subject: [PATCH 4.9 36/38] xen: remove gnttab_query_foreign_access() Date: Thu, 10 Mar 2022 15:13:49 +0100 Message-Id: <20220310140809.185890974@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Juergen Gross Commit 1dbd11ca75fe664d3e54607547771d021f531f59 upstream. Remove gnttab_query_foreign_access(), as it is unused and unsafe to use. All previous use cases assumed a grant would not be in use after gnttab_query_foreign_access() returned 0. This information is useless in best case, as it only refers to a situation in the past, which could have changed already. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- drivers/xen/grant-table.c | 19 ------------------- include/xen/grant_table.h | 2 -- 2 files changed, 21 deletions(-) --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -113,13 +113,6 @@ struct gnttab_ops { * return the frame. */ unsigned long (*end_foreign_transfer_ref)(grant_ref_t ref); - /* - * Query the status of a grant entry. Ref parameter is reference of - * queried grant entry, return value is the status of queried entry. - * Detailed status(writing/reading) can be gotten from the return value - * by bit operations. - */ - int (*query_foreign_access)(grant_ref_t ref); }; =20 struct unmap_refs_callback_data { @@ -254,17 +247,6 @@ int gnttab_grant_foreign_access(domid_t } EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access); =20 -static int gnttab_query_foreign_access_v1(grant_ref_t ref) -{ - return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing); -} - -int gnttab_query_foreign_access(grant_ref_t ref) -{ - return gnttab_interface->query_foreign_access(ref); -} -EXPORT_SYMBOL_GPL(gnttab_query_foreign_access); - static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly) { u16 flags, nflags; @@ -1028,7 +1010,6 @@ static const struct gnttab_ops gnttab_v1 .update_entry =3D gnttab_update_entry_v1, .end_foreign_access_ref =3D gnttab_end_foreign_access_ref_v1, .end_foreign_transfer_ref =3D gnttab_end_foreign_transfer_ref_v1, - .query_foreign_access =3D gnttab_query_foreign_access_v1, }; =20 static void gnttab_request_version(void) --- a/include/xen/grant_table.h +++ b/include/xen/grant_table.h @@ -118,8 +118,6 @@ int gnttab_grant_foreign_transfer(domid_ unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref); unsigned long gnttab_end_foreign_transfer(grant_ref_t ref); =20 -int gnttab_query_foreign_access(grant_ref_t ref); - /* * operations on reserved batches of grant references */ From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 340BEC433EF for ; Thu, 10 Mar 2022 14:22:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243492AbiCJOWy (ORCPT ); Thu, 10 Mar 2022 09:22:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244153AbiCJOS5 (ORCPT ); Thu, 10 Mar 2022 09:18:57 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3815EB18BF; Thu, 10 Mar 2022 06:15:38 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A94D8B81E9E; Thu, 10 Mar 2022 14:15:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21A76C340E8; Thu, 10 Mar 2022 14:15:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921736; bh=xhBRfrNy/7380JiHEmW+Fca0kX0t6YqpNMJ42Bk03qA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EoB4uIRU2ow9uMc87PDgQAyzyYwKkDdGa7M+k+7SYxYBTi5pqIgrO9llv9+Im5P2J 2N3SnRPBXf9wfOWYlv4hMJUAZofyhTjZXv0N6YEHKy/mxbEuFEdH5IHmiMUlUgOO+8 Gz+xEz2ojq9hZrvVcS+HlMBx6HBlciscxQQl0OUA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Simon Gaiser , Juergen Gross , Jan Beulich Subject: [PATCH 4.9 37/38] xen/gnttab: fix gnttab_end_foreign_access() without page specified Date: Thu, 10 Mar 2022 15:13:50 +0100 Message-Id: <20220310140809.214707478@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Juergen Gross Commit 42baefac638f06314298087394b982ead9ec444b upstream. gnttab_end_foreign_access() is used to free a grant reference and optionally to free the associated page. In case the grant is still in use by the other side processing is being deferred. This leads to a problem in case no page to be freed is specified by the caller: the caller doesn't know that the page is still mapped by the other side and thus should not be used for other purposes. The correct way to handle this situation is to take an additional reference to the granted page in case handling is being deferred and to drop that reference when the grant reference could be freed finally. This requires that there are no users of gnttab_end_foreign_access() left directly repurposing the granted page after the call, as this might result in clobbered data or information leaks via the not yet freed grant reference. This is part of CVE-2022-23041 / XSA-396. Reported-by: Simon Gaiser Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- drivers/xen/grant-table.c | 30 +++++++++++++++++++++++------- include/xen/grant_table.h | 7 ++++++- 2 files changed, 29 insertions(+), 8 deletions(-) --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -113,6 +113,10 @@ struct gnttab_ops { * return the frame. */ unsigned long (*end_foreign_transfer_ref)(grant_ref_t ref); + /* + * Read the frame number related to a given grant reference. + */ + unsigned long (*read_frame)(grant_ref_t ref); }; =20 struct unmap_refs_callback_data { @@ -277,6 +281,11 @@ int gnttab_end_foreign_access_ref(grant_ } EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref); =20 +static unsigned long gnttab_read_frame_v1(grant_ref_t ref) +{ + return gnttab_shared.v1[ref].frame; +} + struct deferred_entry { struct list_head list; grant_ref_t ref; @@ -306,12 +315,9 @@ static void gnttab_handle_deferred(unsig spin_unlock_irqrestore(&gnttab_list_lock, flags); if (_gnttab_end_foreign_access_ref(entry->ref, entry->ro)) { put_free_entry(entry->ref); - if (entry->page) { - pr_debug("freeing g.e. %#x (pfn %#lx)\n", - entry->ref, page_to_pfn(entry->page)); - put_page(entry->page); - } else - pr_info("freeing g.e. %#x\n", entry->ref); + pr_debug("freeing g.e. %#x (pfn %#lx)\n", + entry->ref, page_to_pfn(entry->page)); + put_page(entry->page); kfree(entry); entry =3D NULL; } else { @@ -336,9 +342,18 @@ static void gnttab_handle_deferred(unsig static void gnttab_add_deferred(grant_ref_t ref, bool readonly, struct page *page) { - struct deferred_entry *entry =3D kmalloc(sizeof(*entry), GFP_ATOMIC); + struct deferred_entry *entry; + gfp_t gfp =3D (in_atomic() || irqs_disabled()) ? GFP_ATOMIC : GFP_KERNEL; const char *what =3D KERN_WARNING "leaking"; =20 + entry =3D kmalloc(sizeof(*entry), gfp); + if (!page) { + unsigned long gfn =3D gnttab_interface->read_frame(ref); + + page =3D pfn_to_page(gfn_to_pfn(gfn)); + get_page(page); + } + if (entry) { unsigned long flags; =20 @@ -1010,6 +1025,7 @@ static const struct gnttab_ops gnttab_v1 .update_entry =3D gnttab_update_entry_v1, .end_foreign_access_ref =3D gnttab_end_foreign_access_ref_v1, .end_foreign_transfer_ref =3D gnttab_end_foreign_transfer_ref_v1, + .read_frame =3D gnttab_read_frame_v1, }; =20 static void gnttab_request_version(void) --- a/include/xen/grant_table.h +++ b/include/xen/grant_table.h @@ -100,7 +100,12 @@ int gnttab_end_foreign_access_ref(grant_ * Note that the granted page might still be accessed (read or write) by t= he * other side after gnttab_end_foreign_access() returns, so even if page w= as * specified as 0 it is not allowed to just reuse the page for other - * purposes immediately. + * purposes immediately. gnttab_end_foreign_access() will take an addition= al + * reference to the granted page in this case, which is dropped only after + * the grant is no longer in use. + * This requires that multi page allocations for areas subject to + * gnttab_end_foreign_access() are done via alloc_pages_exact() (and freei= ng + * via free_pages_exact()) in order to avoid high order pages. */ void gnttab_end_foreign_access(grant_ref_t ref, int readonly, unsigned long page); From nobody Tue Jun 23 05:03:32 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E5C9C433EF for ; Thu, 10 Mar 2022 14:23:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243695AbiCJOYx (ORCPT ); Thu, 10 Mar 2022 09:24:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244221AbiCJOTD (ORCPT ); Thu, 10 Mar 2022 09:19:03 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A08016EA89; Thu, 10 Mar 2022 06:15:46 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B380DB82670; Thu, 10 Mar 2022 14:15:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04FB5C340E8; Thu, 10 Mar 2022 14:15:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646921739; bh=j/EL99Pu2UnuISmJdrysYZRkmrG+zl/CC4wcBIFNKFQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2izOunQE91Ns77DBUm9EBUkwOhTqAww1px4w78JylOZsb0y9dSEndqs958OZRyhA1 VX9aaXnmn8Jw0RXdVvxB2EN8YGOEn5uPxbk66WgTRYRyv4OBa/YVkogUlFv1PQ9BFX OhW0QrYhBkUEmf2B/UpPJgnigmjfmtcxLOD3mg/Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Demi Marie Obenour , Juergen Gross , Jan Beulich Subject: [PATCH 4.9 38/38] xen/netfront: react properly to failing gnttab_end_foreign_access_ref() Date: Thu, 10 Mar 2022 15:13:51 +0100 Message-Id: <20220310140809.242977132@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220310140808.136149678@linuxfoundation.org> References: <20220310140808.136149678@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Juergen Gross Commit 66e3531b33ee51dad17c463b4d9c9f52e341503d upstream. When calling gnttab_end_foreign_access_ref() the returned value must be tested and the reaction to that value should be appropriate. In case of failure in xennet_get_responses() the reaction should not be to crash the system, but to disable the network device. The calls in setup_netfront() can be replaced by calls of gnttab_end_foreign_access(). While at it avoid double free of ring pages and grant references via xennet_disconnect_backend() in this case. This is CVE-2022-23042 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- drivers/net/xen-netfront.c | 48 +++++++++++++++++++++++++++++-----------= ----- 1 file changed, 31 insertions(+), 17 deletions(-) --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -838,7 +838,6 @@ static int xennet_get_responses(struct n int max =3D XEN_NETIF_NR_SLOTS_MIN + (rx->status <=3D RX_COPY_THRESHOLD); int slots =3D 1; int err =3D 0; - unsigned long ret; =20 if (rx->flags & XEN_NETRXF_extra_info) { err =3D xennet_get_extras(queue, extras, rp); @@ -869,8 +868,13 @@ static int xennet_get_responses(struct n goto next; } =20 - ret =3D gnttab_end_foreign_access_ref(ref, 0); - BUG_ON(!ret); + if (!gnttab_end_foreign_access_ref(ref, 0)) { + dev_alert(dev, + "Grant still in use by backend domain\n"); + queue->info->broken =3D true; + dev_alert(dev, "Disabled for further use\n"); + return -EINVAL; + } =20 gnttab_release_grant_reference(&queue->gref_rx_head, ref); =20 @@ -1074,6 +1078,10 @@ static int xennet_poll(struct napi_struc err =3D xennet_get_responses(queue, &rinfo, rp, &tmpq); =20 if (unlikely(err)) { + if (queue->info->broken) { + spin_unlock(&queue->rx_lock); + return 0; + } err: while ((skb =3D __skb_dequeue(&tmpq))) __skb_queue_tail(&errq, skb); @@ -1671,7 +1679,7 @@ static int setup_netfront(struct xenbus_ struct netfront_queue *queue, unsigned int feature_split_evtchn) { struct xen_netif_tx_sring *txs; - struct xen_netif_rx_sring *rxs; + struct xen_netif_rx_sring *rxs =3D NULL; grant_ref_t gref; int err; =20 @@ -1691,21 +1699,21 @@ static int setup_netfront(struct xenbus_ =20 err =3D xenbus_grant_ring(dev, txs, 1, &gref); if (err < 0) - goto grant_tx_ring_fail; + goto fail; queue->tx_ring_ref =3D gref; =20 rxs =3D (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIG= H); if (!rxs) { err =3D -ENOMEM; xenbus_dev_fatal(dev, err, "allocating rx ring page"); - goto alloc_rx_ring_fail; + goto fail; } SHARED_RING_INIT(rxs); FRONT_RING_INIT(&queue->rx, rxs, XEN_PAGE_SIZE); =20 err =3D xenbus_grant_ring(dev, rxs, 1, &gref); if (err < 0) - goto grant_rx_ring_fail; + goto fail; queue->rx_ring_ref =3D gref; =20 if (feature_split_evtchn) @@ -1718,22 +1726,28 @@ static int setup_netfront(struct xenbus_ err =3D setup_netfront_single(queue); =20 if (err) - goto alloc_evtchn_fail; + goto fail; =20 return 0; =20 /* If we fail to setup netfront, it is safe to just revoke access to * granted pages because backend is not accessing it at this point. */ -alloc_evtchn_fail: - gnttab_end_foreign_access_ref(queue->rx_ring_ref, 0); -grant_rx_ring_fail: - free_page((unsigned long)rxs); -alloc_rx_ring_fail: - gnttab_end_foreign_access_ref(queue->tx_ring_ref, 0); -grant_tx_ring_fail: - free_page((unsigned long)txs); -fail: + fail: + if (queue->rx_ring_ref !=3D GRANT_INVALID_REF) { + gnttab_end_foreign_access(queue->rx_ring_ref, 0, + (unsigned long)rxs); + queue->rx_ring_ref =3D GRANT_INVALID_REF; + } else { + free_page((unsigned long)rxs); + } + if (queue->tx_ring_ref !=3D GRANT_INVALID_REF) { + gnttab_end_foreign_access(queue->tx_ring_ref, 0, + (unsigned long)txs); + queue->tx_ring_ref =3D GRANT_INVALID_REF; + } else { + free_page((unsigned long)txs); + } return err; }