On Tue, 2018-01-23 at 10:27 +0100, Ingo Molnar wrote: > * Ingo Molnar <mi...@kernel.org> 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.
smime.p7s
Description: S/MIME cryptographic signature
