[lkml]   [2018]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Avoid speculative indirect calls in kernel
On Thu, 2018-01-04 at 14:51 +0000, Andrew Cooper wrote:
> > * never turn off indirect branch prediction, but use a branch prediction
> > barrier on every mode switch (needed for current AMD microcode)
> Where have you got this idea from?  Using IBPB on every mode switch
> would be an insane overhead to take, and isn't necessary.

AMD *only* has IBPB and not IBRS, but IIRC you don't need to do it on
every context switch into the kernel; only when switching between

> Also, remember that PTI and these mitigations are for orthogonal issues.
> Perhaps it is easiest to refer directly to the Xen SP2 mitigations and
> my commentary of what is going on:
> With the GCC -mindirect-branch=thunk-external support, and microcode,
> Xen will make a boot-time choice between using Retpoline, Lfence (which
> is the better AMD option, and more performant than retpoline), or IBRS
> on Skylake and newer processors where it is strictly necessary, as well
> as using IBPB whenever available.

I need to pull in the AMD lfence alternative for retpoline, giving us a
3-way choice of the existing retpoline thunk, "lfence; jmp *%\reg", and
a bare "jmp *%\reg".

Then the IBRS bits can be added on top.

> It also supports virtualising IBRS for guest usage when the kernel has
> chosen not to use it; a configuration I haven't seen in any of the Linux
> patch series thusfar.

Adding that for KVM is in the Linux IBRS patch set that I've seen.
Didn't we already have a conversation about how the Linux patch set
does it as an atomically-switched MSR while you've done it manually in
Xen because it's faster?[unhandled content-type:application/x-pkcs7-signature]
 \ /
  Last update: 2018-01-04 16:31    [W:0.164 / U:1.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site