git: DragonFly_RELEASE_5_2 Kernel - Additional cpu bug hardening part 1/2
dillon at crater.dragonflybsd.org
Wed Jun 13 21:09:06 PDT 2018
Author: Matthew Dillon <dillon at apollo.backplane.com>
Date: Mon Jun 11 13:43:22 2018 -0700
Kernel - Additional cpu bug hardening part 1/2
* OpenBSD recently made a commit that scraps the use of delayed FP
state saving due to a rumor that the content of FP registers owned
by another process can be speculatively detected when they are
present for the current process, even when the TS bit is used to
force a DNA trap.
This rumor has been circulating for a while. OpenBSD felt that the
lack of responsiveness from Intel forced their hand. Since they've
gone ahead and pushed a fix for this potential problem, we are
going to as well.
* DragonFlyBSD already synchronously saves FP state on switch-out.
However, it only cleans the state up afterwords by calling fninit
and this isn't enough to actually erase the content in the %xmm
registers. We want to continue to use delayed FP state restores
because it saves a considerable amount of switching time when we do
not have to do a FP restore.
Most programs touch the FP registers at startup due to rtld linking,
and more and more programs use the %xmm registers as general purpose
registers. OpenBSD's solution of always proactively saving and
restoring FP state is a reasonable one. DragonFlyBSD is going to
take a slightly different tact in order to try to retain more optimal
switching behavior when the FP unit is not in continuous use.
* Our first fix is to issue a FP restore on dummy state after our
FP save to guarantee that all FP registers are zerod after FP state
is saved. This allows us to continue to support delayed FP state
loads with zero chance of leakage between processes.
* Our second fix is to add a heuristic which allows the kernel to
detect when the FP unit is being used seriously (verses just during
We have added a sysctl machdep.npx_fpu_heuristic heuristic for this
purpose which defaults to the value 32. Values can be:
0 - Proactive FPU state loading disabled (old behavior retained).
Note that the first fix remains active, the FP register state
is still cleared after saving so no leakage can occur. All
processes will take a DNA trap after a thread switch when they
access the FP state.
1 - Proactive FPU state loading is enabled at all times for a thread
after the first FP access made by that thread. Upon returning
from a thread switch, the FPU state will already be ready to go
and a DNA trap will not occur.
N - Proactive FPU state loading enabled for N context switches, then
disabled. The next DNA fault after disablement then re-enables
proactive loading for the next N context switches.
Default value is 32. This ensures that program startup can use
the FP unit but integer-centric programs which don't afterwords
will not incur the FP switching overhead (for either switch-away
Summary of changes:
sys/platform/pc64/include/globaldata.h | 1 +
sys/platform/pc64/include/md_var.h | 1 +
sys/platform/pc64/x86_64/genassym.c | 2 +
sys/platform/pc64/x86_64/npx.c | 80 +++++++++++++++++++++++++++++++---
sys/platform/pc64/x86_64/swtch.s | 78 +++++++++++++++++++--------------
sys/platform/pc64/x86_64/trap.c | 10 ++++-
sys/platform/vkernel64/x86_64/trap.c | 5 ++-
sys/sys/thread.h | 5 ++-
8 files changed, 138 insertions(+), 44 deletions(-)
DragonFly BSD source repository
More information about the Commits