Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

[Thomas Gleixner]

On Wed, 10 Jan 2018, David Woodhouse wrote:
> On Wed, 2018-01-10 at 11:03 +0100, Peter Zijlstra wrote:
> > On Wed, Jan 10, 2018 at 09:27:59AM +0000, David Woodhouse wrote:
> > > 
> > > > 
> > > > The only question I have is if retpoline works at all on SKL (with ucode
> > > > update); BDW needs the ucode update for retpoline to work because of the
> > > > RSB fallback.
> > > As I understand it, Skylake is never getting the IBRS_ATT (all the
> > > time) feature. That is for future CPUs only.
> >
> > Ah, so then I got confused by your earlier email. So retpoline will work
> > on SKL, but it will, like BDW need the ucode update?
> 
> Er, ... I'm not sure if SKL does need the Âcode update. As I understand
> it, the Âcode update for BDW stops it from taking predictions for 'ret'
> from anything but the RSB, which means that RSB-stuffing is sufficient.
> 
> On SKL I don't think there *is* a way to stop it doing that, which is
> why we were originally saying we'd use IBRS on SKL instead.
> 
> Do ask someone who works at Intel for confirmation of the above :)

To get how many contradicting answers? I'm really fed up with the
desinformation politics in this matter.

> > > I don't know why you're calling that 'IBRS=2'; are you getting confused
> > > by Andrea's distro horridness?
> > Yes, continuation of the nomenclature of that earlier thread.
> 
> Except I don't think it is; I think the various IBRS= options there
> were about pointlessly fine-tuning when you frob the *existing* IBRS
> bit, not about the future IBRS_ATT bit which really is set-and-forget.

So we can offer the spectre_v2=ibrs option now, which just enforces it and
be done with it. The auto mode will not select IBRS.

The question remains, whether retpoline needs to be still in place even
with IBRS enabled. I'd say yes, unless the IBRS always on mechanics fully
works as intended. But that's not a question we have to answer today.

As Ingo stated, we also can require to have microcode early, which is in
fact a single initrd/reboot required. With the flood of reboots we've seen
in the last week and which will continue a while that really should not
matter at all. But we can avoid all the complexity of late switching and
other crap.

> > Still, point remains, do we ever need that MSR fiddling dynamic IBRS
> > stuff now that we have retpolines? I would prefer to not have it if
> > there is no compelling reason for it.
> 
> We do want IBPB if we want to protect userspace processes (and VM
> guests) from each other. 

IBPB is an orthogonal feature and that's the one which is also implemented
by AMD, who did not bother with the IBRS voodoo, if my limited knowledge
(READ: Where is the damned documentation (both Intel and AMD)?) is correct.

> Although the attack mode there is relatively hard so *perhaps* we can
> resort to prayer instead?

That's the only thing we can do anyway due to lack of authorative
statements. That lack is either caused by lawyer weaseling or by
fundamental lack of confidence that the operation principles of the CPU are
fully understood. Maybe both. Not very useful in any case.

> For IBRS though... yeah, good question. It *does* give additional
> protection on SKL where 'ret' might get mispredicted and the RSB-
> stuffing is not always guaranteed to be sufficient, but appealing to
> the deity of your choice might also be an acceptable mitigation there?

So the right thing to do is:

   if (spectre_v2_commandline == "ibrs" || !retpoline)
      	ibrs_enable_if_ucode_supports();

   if (retpoline)
        retpoline_select();

We definitely should add spectre_v2=pray as a valid boot option choice.

Thanks,

	tglx