[lkml]   [2018]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

* Ingo Molnar <> 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).

> 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.

- 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.



 \ /
  Last update: 2018-01-23 10:29    [W:0.112 / U:8.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site