commit 353dee63e80023e526ebaf5e7801cf71c811b8cf Author: Matthew Dillon <dil...@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 program startup). 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 or switch-back). 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(-) http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/353dee63e80023e526ebaf5e7801cf71c811b8cf -- DragonFly BSD source repository