[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
* David Woodhouse <> wrote:

> But wait, why did I say "mostly"? Well, not everyone has a retpoline
> compiler yet... but OK, screw them; they need to update.
> Then there's Skylake, and that generation of CPU cores. For complicated
> reasons they actually end up being vulnerable not just on indirect
> branches, but also on a 'ret' in some circumstances (such as 16+ CALLs
> in a deep chain).
> The IBRS solution, ugly though it is, did address that. Retpoline
> doesn't. There are patches being floated to detect and prevent deep
> stacks, and deal with some of the other special cases that bite on SKL,
> but those are icky too. And in fact IBRS performance isn't anywhere
> near as bad on this generation of CPUs as it is on earlier CPUs
> *anyway*, which makes it not quite so insane to *contemplate* using it
> as Intel proposed.

There's another possible method to avoid deep stacks on Skylake, without compiler

- Use the existing mcount based function tracing live patching machinery
(CONFIG_FUNCTION_TRACER=y) to install a _very_ fast and simple stack depth
tracking tracer which would issue a retpoline when stack depth crosses
boundaries of ~16 entries.

The overhead of that would _still_ very likely be much cheaper than a hundreds
(thousands) of cycle expensive MSR write at every kernel entry (syscall entry, IRQ
entry, etc.).

Note the huge number of advantages:

- All distro kernels already enable the mcount based patching options, so there's
literally zero overhead to anything except SkyLake.

- It is fully kernel patching based and can be activated on Skylake only

- It doesn't require any microcode updates, so it will work on all existing CPUs
with no firmware or microcode modificatons

- It doesn't require any compiler updates

- SkyLake performance is very likely to be much less fragile than relying on a
hastily deployed microcode hack

- The "SkyLake stack depth tracer" can be tested on other CPUs as well in debug
builds, broadening the testing base

- The tracer is very obviously simple and reviewable, and we can forget about it
in the far future.

- It's much more backportable to older kernels: should there be a new class of
exploits then this machinery could be updated to cover that too - while
upgrades to newer kernels would give the higher performant solution.

Yes, there are some practical complications like always enabling
CONFIG_FUNCTION_TRACER=y on x86, plus the ftrace interaction has to be sorted out,
but in practice it's enabled on all major distros anyway, due to ftrace.

Is there any reason why this wouldn't work?



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