From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE92811703 for ; Mon, 21 Aug 2023 20:05:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F260C433C7; Mon, 21 Aug 2023 20:05:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1692648312; bh=zT1pPN4NJ8eIRdh8stujh7UAwsJZjQzDnUMUzKePI2A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jTQI1eH9fqKN2HcslNxlIy+rfcrdktmil9S+9nzqGJ6u57q+GUAR1Rs39QRXOu/8F UzLI93zfWvgbjoZqPkRfjUTGljumTOcjcyMIcmvbVUXxNlAIdh1IaxqlF26unJXZnv XUbMHhEu554AV0XE1D+gPUy4S7g5WiRs+7KAVRCI= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, "Borislav Petkov (AMD)" Subject: [PATCH 6.4 123/234] x86/srso: Explain the untraining sequences a bit more Date: Mon, 21 Aug 2023 21:41:26 +0200 Message-ID: <20230821194134.259712546@linuxfoundation.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230821194128.754601642@linuxfoundation.org> References: <20230821194128.754601642@linuxfoundation.org> User-Agent: quilt/0.67 Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Borislav Petkov (AMD) commit 9dbd23e42ff0b10c9b02c9e649c76e5228241a8e upstream. 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 Signed-off-by: Greg Kroah-Hartman --- arch/x86/lib/retpoline.S | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) --- 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) /* + * 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.