Clarifying the Spectre mitigations...

[Matthew Dillon]

IBRS in mode 2 (i.e. always leaving it on) results in a 30%+ performance
hit to everything, at least on older cpus.  This is not a complete
mitigation either, it's really just a bad microcode hack by Intel that
nobody really wants to have to turn on.

IBRS in mode 1 (i.e. just during kernel execution and not during user
execution) will significantly impact anything that uses the kernel heavily,
such as the network stack.  This mode will not protect against the most
common like Spectre attack (which is a javascript attack against the
browser it is running it).

RetPoline is only a partial mitigation.

MMU isolation + IBRS mode 2 increases system call overhead to over 800nS.

--

In terms of DragonFlyBSD, MMU isolation is now built into master.  IBRS and
RetPoline are not, yet.  I'm still evaluating them, and in fact for IBRS
(aka Spectre Attacks) it isn't just Intel, but AMD is also doing a
microcode update and I have no information on their implementation yet.
It is possible to run DragonFlyBSD with mode 2 IBRS right now by installing
the appropriate microcode update from Intel using cpucontrol, and turn IBRS
on with cpucontrol MSR ops.  But my recommendation is that people not try
to shortcut Specter protections... wait until we finish evaluating it and
get something in the system.

I'll be honest... I personally do not think there is a viable protection
against Spectre possible on Intel, even with the microcode IBRS stuff.
Turning on the best possible mitigation (IBRS mode 2) destroys the
performance of the machine across all applications and use cases.  If you
want to play with IBRS mode 2:

* I found a microcode archive at
https://launchpad.net/ubuntu/+source/intel-microcode/3.20171215.1 (I don't
know if it is the latest one)

kldload cpuctl
pkg install devcpu-data

unpack the tar archive and move the *.fw files into
/usr/local/share/cpucontrol/

See if you can apply the microcode updates:

cpucontrol -u /dev/cpuctl0
cpucontrol -u /dev/cpuctl1
cpucontrol -u /dev/cpuctl2
cpucontrol -u /dev/cpuctl3
... for all cpu cores (hyperthreads will be ignored)

See if there is IBRS support:

test40# cpucontrol -i 7,0 /dev/cpuctl0  (BEFORE MICROCODE UPDATE)
cpuid level 0x7, level_type 0x0: 0x00000000 blah 0x00000000 0x00000000

test40# cpucontrol -i 7,0 /dev/cpuctl0  (AFTER MICROCODE UPDATE)
cpuid level 0x7, level_type 0x0: 0x00000000 blah 0x00000000 0x0c000000

If you get the 0C in the last word, there is IBRS support.  You can try
turning it on with cpucontrol.


cpucontrol -m 48=1 /dev/cpuctl0
  .... do for all cpus ...

That is 95% of IBRS mode 2.  But be prepared for a performance implosion.
Also, Intel might not have a microcode update for whatever cpu you are on
yet (or ever).

-Matt

On Sun, Jan 7, 2018 at 5:23 AM, my123 (@never_released) <
securetalk at sbmobilepilot.onmicrosoft.com> wrote:

> Hi,
>
> The kernel is protected against Spectre  with retpoline but
> application-specific patches are required except when IBPB=2 + STIBP,
> IBRS=1 + IBPB=1, or IBRS=2 are used.
>
> IBPB is a branch prediction barrier that solves Spectre on its maximum
> setting, but it comes with a performance hit. It requires enabling STIBP
> for full protection too, except when hyperthreading is disabled.
>
> IBRS is the restricted indirect branch speculation feature, which solves
> Spectre on its maximum setting, except for VM isolation but requires a
> performance hit too. In order to protect virtual machines from other
> virtual machines, ibpb=1 is needed even if ibrs is set to 2..
>
> IBPB=1 *and* IBRS=1 works too but it causes a performance hit, and IBRS=2
> + IBPB=1 is needed for isolation between virtual machines, but isn't
> required when VMs aren't used.
>
> AMD implements IBRS and IBPB for CPU families before 17h (Zen), but only
> IBPB and STIBP for Zen.
>
> All those features require newer microcode to work... and the impact on
> performance is not zero.
>
> The alternative is recompiling every sensitive thing with retpoline...
> which is what Linux is trying to implement on mainline. On Windows, as
> convincing developers to update their toolchain is hard there, IBRS and
> IBPB are used there despite the performance hit.
>
> Hoping that I made things a bit clearer...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20180108/459ef65c/attachment-0003.htm>