Re: [PATCH 2/2] x86/bugs: Don't fill RSB on context switch with eIBRS

["Shah, Amit" <Amit.Shah@amd.com>]

On Wed, 2024-11-20 at 08:21 -0800, jpoimboe@kernel.org 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