On 07/25/2018 10:11 AM, Josh Poimboeuf wrote: > 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 <jkos...@suse.cz> >>> >>> 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.
I think that's correct. IBPB does flushes the RSB. But doing RSB stuffing will be cheaper. Tim > > 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 <jpoim...@redhat.com> >
