[AMD Official Use Only - AMD Internal Distribution Only] > -----Original Message----- > From: Josh Poimboeuf <jpoimboe@xxxxxxxxxx> > Sent: Monday, November 11, 2024 1:33 PM > To: Amit Shah <amit@xxxxxxxxxx> > Cc: linux-kernel@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; x86@xxxxxxxxxx; linux- > doc@xxxxxxxxxxxxxxx; Shah, Amit <Amit.Shah@xxxxxxx>; Lendacky, Thomas > <Thomas.Lendacky@xxxxxxx>; bp@xxxxxxxxx; tglx@xxxxxxxxxxxxx; > peterz@xxxxxxxxxxxxx; pawan.kumar.gupta@xxxxxxxxxxxxxxx; corbet@xxxxxxx; > mingo@xxxxxxxxxx; dave.hansen@xxxxxxxxxxxxxxx; hpa@xxxxxxxxx; > seanjc@xxxxxxxxxx; pbonzini@xxxxxxxxxx; daniel.sneddon@xxxxxxxxxxxxxxx; > kai.huang@xxxxxxxxx; Das1, Sandipan <Sandipan.Das@xxxxxxx>; > boris.ostrovsky@xxxxxxxxxx; Moger, Babu <Babu.Moger@xxxxxxx>; Kaplan, > David <David.Kaplan@xxxxxxx>; dwmw@xxxxxxxxxxxx; > andrew.cooper3@xxxxxxxxxx > Subject: Re: [RFC PATCH v2 1/3] x86: cpu/bugs: update SpectreRSB comments > for AMD > > Caution: This message originated from an External Source. Use proper caution > when opening attachments, clicking links, or responding. > > > On Mon, Nov 11, 2024 at 05:39:11PM +0100, Amit Shah wrote: > > From: Amit Shah <amit.shah@xxxxxxx> > > > > AMD CPUs do not fall back to the BTB when the RSB underflows for RET > > address speculation. AMD CPUs have not needed to stuff the RSB for > > underflow conditions. > > > > The RSB poisoning case is addressed by RSB filling - clean up the > > FIXME comment about it. > > I'm thinking the comments need more clarification in light of BTC and SRSO. > > This: > > > - * AMD has it even worse: *all* returns are speculated from the BTB, > > - * regardless of the state of the RSB. > > is still true (mostly: "all" should be "some"), though it doesn't belong in the "RSB > underflow" section. > > Also the RSB stuffing not only mitigates RET, it mitigates any other instruction > which happen to be predicted as a RET. Which is presumably why it's still needed > even when SRSO is enabled. > While that's partly true, I'm not sure I'm understanding which scenario you're concerned with. As noted in the AMD BTC whitepaper, there are various types of potential mis-speculation depending on what the actual branch is. The 'late redirect' ones are the most concerning since those have enough of a speculation window to be able to do a load-op-load gadget. The only 'late redirect' case involving an instruction being incorrectly predicted as a RET is when the actual instruction is an indirect JMP/CALL. But those instructions are either removed entirely (due to retpoline) or being protected with IBRS. The cases of other instructions (like Jcc) being predicted as a RET are subject to the 'early redirect' behavior which is much more limited (and note that these can also be predicted as indirect branches for which there is no special protection). So I'm not sure why BTC specifically would necessitate needing to stuff the RSB here. Also, BTC only affects some AMD parts (not Family 19h and later for instance). --David Kaplan