On Wed, 2024-11-20 at 08:21 -0800, jpoimboe@xxxxxxxxxx wrote: > On Wed, Nov 20, 2024 at 10:27:42AM +0000, Shah, Amit wrote: > > On Tue, 2024-11-19 at 23:27 -0800, Josh Poimboeuf wrote: > > > User->user Spectre v2 attacks (including RSB) across context > > > switches > > > are already mitigated by IBPB in cond_mitigation(), if enabled > > > globally > > > or if at least one of the tasks has opted in to protection. RSB > > > filling > > > without IBPB serves no purpose for protecting user space, as > > > indirect > > > branches are still vulnerable. > > > > > > User->kernel RSB attacks are mitigated by eIBRS. In which case > > > the > > > RSB > > > filling on context switch isn't needed. Fix that. > > > > > > While at it, update and coalesce the comments describing the > > > various > > > RSB > > > mitigations. > > > > Looks good from first impressions - but there's something that > > needs > > some deeper analysis: AMD's Automatic IBRS piggybacks on eIBRS, and > > has > > some special cases. Adding Kim to CC to check and confirm if > > everything's still as expected. > > FWIW, so "Technical Guidance for Mitigating Branch Type Confusion" > has > the following: > > Finally, branches that are predicted as ‘ret’ instructions get > their > predicted targets from the Return Address Predictor (RAP). AMD > recommends software use a RAP stuffing sequence (mitigation V2-3 in > [2]) and/or Supervisor Mode Execution Protection (SMEP) to ensure > that > the addresses in the RAP are safe for speculation. Collectively, we > refer to these mitigations as “RAP Protection”. > > So it sounds like user->kernel RAP poisoning is mitigated by SMEP on > AMD. It indeed is. I'm just asking Kim to confirm whether the AutoIBRS workflow can be updated based on this rework -- esp with disabling it for SEV-SNP hosts. I just went through those patches, and it doesn't look like anything needs changing. Amit
