master now has full ibrs and ibpb support - notes

[Matthew Dillon]

Hey everyone.  Ok, DFly master now has full ibrs and ibpb support.  If your
system has a microcode that supports it, or you load a new microcode that
supports it, master will default to IBRS mode 1 operation.

IBRS mode 1 operation will protect the kernel (even without the kernel
having RetPoline), and will also protect between user contexts, but will
not protect attacks within the same user context (such as a browser
Javascript attack against the browser itself).  For that I point people to
our chrome wiki page with instructions on how to do multi-layered
protection of the chrome browser.

https://www.dragonflybsd.org/docs/docs/handbook/RunSecureBrowser/

If you want to run IBRS in mode 2 you can, but it won't add a whole lot to
the mode 1 protections and it comes at a high cost.   Essentially IBRS mode
2 is designed for future chipsets and microcodes which will have a new IBRS
but which can just be set and forgotten.  The current mode 2 operation
still requires that the kernel issue a wrmsr for IBRS on every user->kernel
transition.

IBPB is primarily designed to solve certain hardware virtualization issues
and is not needed for user->kernel transitions when IBRS is enabled, so we
recommennd leaving IBPB mode turned off.  This also requires a microcode
update that supports it.  Eventually IBPB on future processors may wind up
being faster than IBRS as IBPB imposes a strict barrier and the cpu runs at
full speed before and after.  But right now the microcode IBPB
implementations have a 2uS (2000nS) latency associated with them, so IBRS
mode 1 is typically faster.

Most BIOS vendors do NOT yet have microcode updates.  Intel has microcode
updates but they haven't been integrated into our devcpu-data package yet
and it takes a small bit of effort to translate the intel-supplied
microcode to the .fw format that cpucontrol needs.  But I expect this will
change soon.

--

We do not have AMD support yet, because there are no publically available
AMD microcodes for Ryzen that I can find to test with which have these
features.  AMD is generally less vulnerable and will likely use IBRS=0
IBPB=1.  I do not know what the AMD IBPB is going to cost us, yet, though.

--

I have included a general loss-of-performance matrix below so people can
get an idea of the cost.  I have included MMU isolation overheads assuming
4% overhead for Haswell and 2% overhead for Skylake and Kabylake for MMU
isolation.  This loss matrix is based on a time make -j 8 nativekernel
NO_MODULES=TRUE, which is a good concurrent compile test.  A very general
case.  Obviously different workloads are going to have wildly different
performance loss figures, but this matrix will give you a pretty good idea
at what the cost is.

These tests are just with CPUs I have handy and by no means complete.

                        Performance Loss Matrix
               Using Highly concurrent compile test case
                     INCLUDING MMU ISOLATION
           HASWELL                 SKYLAKE                KABYLAKE-U
        IBPB=0  IBPB=1          IBPB=0  IBPB=1        IBPB=0  IBPB=1
IBRS=0     4%    16%              2%      19%            2%      19%
IBRS=1    16%    25%            4.4%     17%          4.0%     20%
IBRS=2    62%    64%             25%     34%           21%     31%

Keeping in mind that the default setting will be IBRS=1 IBPB=0.  As you can
see, older CPUs such as Haswell are the most impacted, while more recent
CPUs are far less impacted.

--

In DragonFlyBSD master, the machdep.spectre_mitigation sysctl can be used
(if the microcode supports it) to set the mode of operation at any time.

mode
0    IBRS=0  IBPB=0
1    IBRS=1  IBPB=0
2    IBRS=2  IBPB=0

4    IBRS=0  IBPB=1
5    IBRS=1  IBPB=1
6    IBRS=2  IBPB=1

And the machdep.meltdown_mitigation sysctl can turn on/off MMU isolation
(0=OFF, 1=ON), default will be on for Intel CPUs and off for AMD CPUs for
now.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20180110/0d057ef9/attachment-0002.htm>