Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

From: Josh Poimboeuf
Date: Wed Jul 25 2018 - 13:11:32 EST


On Wed, Jul 25, 2018 at 03:50:44PM +0200, Jiri Kosina wrote:
> On Wed, 25 Jul 2018, Josh Poimboeuf wrote:
>
> > > The article "Spectre Returns! Speculation Attacks using the Return Stack
> > > Buffer" [1] describes two new (sub-)variants of spectrev2-like attack,
> > > making use solely of the RSB contents even on CPUs that don't fallback to
> > > BTB on RSB underflow (Skylake+).
> > >
> > > Mitigate userspace-userspace attacks by always unconditionally filling RSB on
> > > context switch when generic spectrev2 mitigation has been enabled.
> > >
> > > [1] https://arxiv.org/pdf/1807.07940.pdf
> > >
> > > Signed-off-by: Jiri Kosina <jkosina@xxxxxxx>
> >
> > While I generally agree with this patch, isn't it odd that we would do
> > RSB filling on every context switch, but almost never do IBPB?
>
> Yeah, I have actually been wondering exactly the same, but that's what we
> have been doing so far on SKL+, so I didn't really want to mix this aspect
> in.
>
> I actually believe that in the name of consistency we should've been doing
> the RSB fills under the same conditions we're issuing IBPB even on SKL+; I
> can resend a patch that re-adjusts that, if that's the consensus.

True, in theory it might make more sense to only fill RSB when doing an
IBPB. But given the current state of almost never doing IBPB, that
would be pointless. RSB is cheap enough that we should just do it
unconditionally on context switch.

BTW, I've heard that IBPB actually flushes RSB, though I haven't seen
that officially documented anywhere. Not that it matters given the
current IBPB code.

BTW^2, there was some discussion a few months back about offloading the
"when to IBPB" decision to security modules, though I don't think I've
ever seen official patches for that.

All that said, this patch is fine until if/when the IBPB strategy gets
figured out. RSB filling is cheap.

Reviewed-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>

--
Josh