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 822BCC7EE2D for ; Mon, 27 Feb 2023 19:59:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229977AbjB0T7N (ORCPT ); Mon, 27 Feb 2023 14:59:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229671AbjB0T7L (ORCPT ); Mon, 27 Feb 2023 14:59:11 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45AD546A2; Mon, 27 Feb 2023 11:59:10 -0800 (PST) Date: Mon, 27 Feb 2023 19:58:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1677527940; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+v/s65Lv8BRxdKYlYRq8m7npHhRAde86BqkA1lCMCJk=; b=Z6qj6Jeso8U9KM7Av5i0anLDAxTCMRyI4JvnyEKyamHWUvnPG2ugxmY0jU07VhmIeveAfn UJJYq09uK0+j08kxtedAMDW95ibczwGU+TqrXDX85xcVpw3CGxckHmSYhdg5FTeszB4w4v IXSKASU7tU8mC11vJyDg/vi2eb0c5NGRtOtHrbOc0AZwMofBpYO+tQfUE+QpOoVFdCTTnH Q//5Chhw9KsThOWdKQ+MVuAdIe+8YWFGDO/o8KYWZz8vlUF/GW/oYS8avaJt/KFKde+Vs3 fa+OhqDCFXkuqTMVBfdwVDmCEIibhVUuQ94jdW5tuf3I1UJ2b1A7jlx/ErL1LQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1677527940; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+v/s65Lv8BRxdKYlYRq8m7npHhRAde86BqkA1lCMCJk=; b=eYBNs0r+l71lSyyK9Gr1uOZ0Pz6E83PrlsGd7beqfi8PzRGLRsDCZXEoWXHhj85NDinhPA WwEQbI2UjOJ6vTBw== From: "tip-bot2 for KP Singh" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/urgent] Documentation/hw-vuln: Document the interaction between IBRS and STIBP Cc: KP Singh , "Borislav Petkov (AMD)" , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20230227060541.1939092-2-kpsingh@kernel.org> References: <20230227060541.1939092-2-kpsingh@kernel.org> MIME-Version: 1.0 Message-ID: <167752793989.5837.12551324006381461991.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the x86/urgent branch of tip: Commit-ID: e02b50ca442e88122e1302d4dbc1b71a4808c13f Gitweb: https://git.kernel.org/tip/e02b50ca442e88122e1302d4dbc1b71a4808c13f Author: KP Singh AuthorDate: Mon, 27 Feb 2023 07:05:41 +01:00 Committer: Borislav Petkov (AMD) CommitterDate: Mon, 27 Feb 2023 19:02:47 +01:00 Documentation/hw-vuln: Document the interaction between IBRS and STIBP Explain why STIBP is needed with legacy IBRS as currently implemented (KERNEL_IBRS) and why STIBP is not needed when enhanced IBRS is enabled. Fixes: 7c693f54c873 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS") Signed-off-by: KP Singh Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230227060541.1939092-2-kpsingh@kernel.org --- Documentation/admin-guide/hw-vuln/spectre.rst | 21 +++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index 3fe6511..4d186f5 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -479,8 +479,16 @@ Spectre variant 2 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. + On CPUs with hardware mitigation for Spectre variant 2 (e.g. IBRS + or enhanced IBRS on x86), retpoline is automatically disabled at run time. + + Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at + boot, by setting the IBRS bit, and they're automatically protected against + Spectre v2 variant attacks, including cross-thread branch target injections + on SMT systems (STIBP). In other words, eIBRS enables STIBP too. + + Legacy IBRS systems clear the IBRS bit on exit to userspace and + therefore explicitly enable STIBP for that The retpoline mitigation is turned on by default on vulnerable CPUs. It can be forced on or off by the administrator @@ -504,9 +512,12 @@ Spectre variant 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 :ref:`Documentation/userspace-api/spec_ctrl.rst `). + target buffer left by malicious software. + + On legacy IBRS systems, at return to userspace, implicit STIBP is disabled + because the kernel clears the IBRS bit. In this case, the userspace programs + can disable indirect branch speculation via prctl() (See + :ref:`Documentation/userspace-api/spec_ctrl.rst `). 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.