On Mon, Nov 11, 2024 at 07:58:03PM +0000, Kaplan, David wrote: > > 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). This is why it's important to spell out all the different cases in the comments. I was attempting to document the justifications for the existing behavior. You make some good points, though backing up a bit, I realize my comment was flawed for another reason: the return thunks only protect the kernel, but RSB filling on context switch is meant to protect user space. So, never mind... -- Josh
