Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

[David Woodhouse]

On Tue, 2018-01-23 at 10:27 +0100, Ingo Molnar wrote:
> * Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> 
> > 
> > Is there a testcase for the SkyLake 16-deep-call-stack problem that I could run?Â
> > Is there a description of the exact speculative execution vulnerability that hasÂ
> > to be addressed to begin with?
>
> Ok, so for now I'm assuming that this is the 16 entries return-stack-bufferÂ
> underflow condition where SkyLake falls back to the branch predictor (while otherÂ
> CPUs wrap the buffer).

Yep.

> > 
> > If this approach is workable I'd much prefer it to any MSR writes in the syscallÂ
> > entry path not just because it's fast enough in practice to not be turned off byÂ
> > everyone, but also because everyone would agree that per function call overheadÂ
> > needs to go away on new CPUs. Both deployment and backporting is also _much_ moreÂ
> > flexible, simpler, faster and more complete than microcode/firmware or compilerÂ
> > based solutions.
> > 
> > Assuming the vulnerability can be addressed via this route that is, which is a bigÂ
> > assumption!
>
> So I talked this over with PeterZ, and I think it's all doable:
> 
> Â- the CALL __fentry__ callbacks maintain the depth tracking (on the kernelÂ
> ÂÂÂstack, fast to access), and issue an "RSB-stuffing sequence" when depth reaches
> ÂÂÂ16 entries.
> 
> Â- "the RSB-stuffing sequence" is a return trampoline that pushes a CALL on theÂ
> ÂÂÂstack which is executed on the RET.

That's neat. We'll want to make sure the unwinder can cope but hey,
Peter *loves* hacking objtool, right? :)

> Â- All asynchronous contexts (IRQs, NMIs, etc.) stuff the RSB before IRET. (TheÂ
> ÂÂÂtracking could probably made IRQ and maybe even NMI safe, but the worst-caseÂ
> ÂÂÂnesting scenarios make my head ache.)
> 
> I.e. IBRS can be mostly replaced with a kernel based solution that is better thanÂ
> IBRS and which does not negatively impact any other non-SkyLake CPUs or generalÂ
> code quality.
> 
> I.e. a full upstream Spectre solution.

Sounds good. I look forward to seeing it.

In the meantime I'll resend the basic bits of the feature detection and
especially turning off KPTI when RDCL_NO is set.

We do also want to do IBPB even with retpoline, so I'll send those
patches for KVM and context switch. There is some bikeshedding to be
done there about the precise conditions under which we do it.

Finally, KVM should be *exposing* IBRS to guests even if we don't use
it ourselves. We'll do that too.

Attachment: smime.p7s
Description: S/MIME cryptographic signature