From nobody Wed Dec 17 19:37:33 2025 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 7459EC41513 for ; Wed, 16 Aug 2023 21:21:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346450AbjHPVU3 (ORCPT ); Wed, 16 Aug 2023 17:20:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57376 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346451AbjHPVUL (ORCPT ); Wed, 16 Aug 2023 17:20:11 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5DBC61990; Wed, 16 Aug 2023 14:20:10 -0700 (PDT) Date: Wed, 16 Aug 2023 21:20:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1692220807; 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=DYeNZ4oVgT3ZF4QvvRaJIKw84ssyIQNlEymOhPV8od8=; b=YpuEgmVVeRTSTAtLcf/6B9fk3sdaIFtINxVd4kKPjixProblyBtm6kWeyoVCEWe8u5FXS4 GJWGOuw1+MB7dbN6rg1axiodOybMlg60IK2iEbiJCuyKJZ+e4pr8Qg5KpW0eI6hZKH+G2X Bc7Rfp+1Oc3IHlisJit7blgb4U3kkJEG2SlA66ztcwVwph+SxTdEAzLyMDG6ZvYNq9vus8 pJ5Y7i2HJYy/loMz1Tlnm+Ro64la1LRkuglBr6mz/sf/jHPMz4i6S/gzAI6pMf6/j4dIK6 2n92/5XijD+EV7H5XjbWg/i0+/IOmUqU8Zkg8dNAnVt1or+XfgI8sYcX8Jt+tQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1692220807; 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=DYeNZ4oVgT3ZF4QvvRaJIKw84ssyIQNlEymOhPV8od8=; b=teg4ViG5mXfgIZ/XY/fbiPJ/KYvI0WLXx3B67Z8Ud8FqyP0XwtE2m2HYX4WTVF+wvN6OQ2 ZU/oCGOclrUa+gCw== From: "tip-bot2 for Borislav Petkov (AMD)" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/urgent] x86/srso: Explain the untraining sequences a bit more Cc: "Borislav Petkov (AMD)" , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <64H4lENIe94@fat_crate.local> References: <64H4lENIe94@fat_crate.local> MIME-Version: 1.0 Message-ID: <169222080701.27769.16891870244116841745.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: quoted-printable 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: 9dbd23e42ff0b10c9b02c9e649c76e5228241a8e Gitweb: https://git.kernel.org/tip/9dbd23e42ff0b10c9b02c9e649c76e522= 8241a8e Author: Borislav Petkov (AMD) AuthorDate: Mon, 14 Aug 2023 21:29:50 +02:00 Committer: Borislav Petkov (AMD) CommitterDate: Wed, 16 Aug 2023 21:58:59 +02:00 x86/srso: Explain the untraining sequences a bit more The goal is to eventually have a proper documentation about all this. Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230814164447.GFZNpZ/64H4lENIe94@fat_crate= .local --- arch/x86/lib/retpoline.S | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/arch/x86/lib/retpoline.S b/arch/x86/lib/retpoline.S index 5e85da1..cd86aeb 100644 --- a/arch/x86/lib/retpoline.S +++ b/arch/x86/lib/retpoline.S @@ -187,6 +187,25 @@ SYM_CODE_START(srso_alias_return_thunk) SYM_CODE_END(srso_alias_return_thunk) =20 /* + * Some generic notes on the untraining sequences: + * + * They are interchangeable when it comes to flushing potentially wrong + * RET predictions from the BTB. + * + * The SRSO Zen1/2 (MOVABS) untraining sequence is longer than the + * Retbleed sequence because the return sequence done there + * (srso_safe_ret()) is longer and the return sequence must fully nest + * (end before) the untraining sequence. Therefore, the untraining + * sequence must fully overlap the return sequence. + * + * Regarding alignment - the instructions which need to be untrained, + * must all start at a cacheline boundary for Zen1/2 generations. That + * is, instruction sequences starting at srso_safe_ret() and + * the respective instruction sequences at retbleed_return_thunk() + * must start at a cacheline boundary. + */ + +/* * Safety details here pertain to the AMD Zen{1,2} microarchitecture: * 1) The RET at retbleed_return_thunk must be on a 64 byte boundary, for * alignment within the BTB.