Re: [PATCH 2/2] x86/bugs: Don't fill RSB on context switch with eIBRS
From: Shah, Amit
Date: Thu Nov 21 2024 - 08:28:42 EST
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