Messages in this thread | | | Date | Tue, 15 Aug 2023 18:41:58 +0300 | Subject | Re: [PATCH] x86/srso: Explain the untraining sequences a bit more | From | Nikolay Borisov <> |
| |
On 15.08.23 г. 17:26 ч., Borislav Petkov wrote: > From: "Borislav Petkov (AMD)" <bp@alien8.de> > Date: Mon, 14 Aug 2023 21:29:50 +0200 > > The goal is to eventually have a proper documentation about all this. > > Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> > > diff --git a/arch/x86/lib/retpoline.S b/arch/x86/lib/retpoline.S > index 915c4fe17718..e59c46581bbb 100644 > --- a/arch/x86/lib/retpoline.S > +++ b/arch/x86/lib/retpoline.S > @@ -183,6 +183,25 @@ SYM_CODE_START(srso_alias_return_thunk) > ud2 > 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. > + */
Are there any salient generic details about zen 3/4 ? > + > /* > * 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
| |