Messages in this thread | | | Subject | Re: Avoid speculative indirect calls in kernel | Date | Thu, 4 Jan 2018 15:29:37 +0000 | From | "Woodhouse, David" <> |
| |
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 VMs/processes?
> 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: > http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=blob;f=xen/arch/x86/spec_ctrl.c;h=79aedf774a390293dfd564ce978500085344e305;hb=refs/heads/sp2-mitigations-v6.5#l192 > > 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] | |