kernel - Add MDS mitigation support for Intel side-channel attack

* Add MDS (Microarchitectural Data Sampling) attack mitigation to
the kernel. This is an attack against Intel CPUs made from 2011

kernel - Add MDS mitigation support for Intel side-channel attack

* Add MDS (Microarchitectural Data Sampling) attack mitigation to
the kernel. This is an attack against Intel CPUs made from 2011
to date. The attack is not currently known to work against AMD CPUs.

With an intel microcode update the mitigation can be enabled with

sysctl machdep.mds_mitigation=MD_CLEAR

* Without the intel microcode update, only disabling hyper-threading
gives you any protection. Older architectures might not get
support. If sysctl machdep.mds_support does not show support,
then the currently loaded microcode does not have support for the
feature.

* DragonFlyBSD only supports the MD_CLEAR mode, and it will only
be available with a microcode update from Intel.

Updating the microcode alone does not protect against the attack.
The microcode must be updated AND the mode must be turned on in
DragonFlyBSD to protect against the attack.

This mitigation burns around 250nS of additional latency on kernel->user
transitions (system calls and interrupts primarily). The additional
latency will not be present if the microcode has support but it is disabled
in the kernel, so you should be able to safely update your microcode
even if you do not intend to use the mitigation.

* It is unclear whether the microcode + mitigation completely protects
the machine. The attack is supposedly a sibling hyper-thread
attack and it may be that the only way to completely protect your
machine is to disable hyper-threading entirely. Or buy AMD.

Templated-from: NetBSD

show more ...

kernel - Flesh out Spectre mitigation support

* Add handling for all modes for AMD CPUs, including support for
IBRS_AUTO and STIBP_AUTO (always-on) bits which will be added
to future cpus.

* Ad

kernel - Flesh out Spectre mitigation support

* Add handling for all modes for AMD CPUs, including support for
IBRS_AUTO and STIBP_AUTO (always-on) bits which will be added
to future cpus.

* Add STIBP handling to Intel CPUs. I can't find definitions for
AUTO (always-on) modes for Intel, so those are still not supported
(no current CPU has AUTO support yet anyway).

* Current DragonFlyBSD defaults: Will enable IBRS_AUTO and STIBP_AUTO
(always on) support by default if the cpu has it. Will NOT enable IBRS
or STIBP (non-auto) toggling by default. Will not enable IBPB by default.

IBPB is currently not enabled by default. The overhead is an enormous
~2uS. We will follow Linux in this regard.

* Change the machdep.spectre_mitigation sysctl to take a string of
features to enable. Change machdep.spectre_support to display a
string of features supported. Possible features are:

IBRS Indirect Branch Restricted Speculation (U->K and K->U)
STIBP Single Thread Indirect Branch Prediction (U->K and K->U)
IBPB Branch Prediction Barrier (U->K)
IBRS_AUTO IBRS always-on (set once and forget)
STIBP_AUTO STIBP always-on (set once and forget)

The machdep.spectre_support sysctl tells you whats available.

* Refactor tr_pcb_gflags into tr_pcb_spec_ctrl[2] to make it easier
for the assembly code to program the SPEC_CTRL MSR.

* Note that some of the above bits will never be supported by current
hardware and exist to allow future hardware to support these features
in a less expensive manner.

* Also note that for Meltdown, AMD is immune and the meltdown mitigation
will not be enabled. Intel is vulnerable and the mitigation will be
enabled by default. See sysctl machdep.meltdown_mitigation.

show more ...

kernel - Implement spectre mitigations part 2

* NOTE: The last few commits may have said 'IBPB' but they really
meant 'IBRS. The last few commits addde IBRS support, this one
cleans that up and

kernel - Implement spectre mitigations part 2

* NOTE: The last few commits may have said 'IBPB' but they really
meant 'IBRS. The last few commits addde IBRS support, this one
cleans that up and adds IBPB support.

* Intel says for IBRS always-on mode (mode 2), SPEC_CTRL still has
to be poked on every user->kernel entry as a barrier, even though
the value is not being changed. So make this change. This actually
somewhat improves performance a little on Skylake and later verses
when I just set it globally and left it that way.

* Implement IBPB detection and support on Intel. At the moment
we default to turning it off because the performance hit is pretty
massive. Currently the work on linux is only using IBPB for
VMM related operations and not for user->kernel entry.

* Enhance the machdep.spectre_mitigation sysctl to print out
what the mode matrix is whenever you change it, in human
readable terms.

0 IBRS disabled IBPB disabled
1 IBRS mode 1 (kernel-only) IBPB disabled
2 IBRS mode 2 (at all times) IBPB disabled

4 IBRS disabled IBPB enabled
5 IBRS mode 1 (kernel-only) IBPB enabled
6 IBRS mode 2 (at all times) IBPB enabled

Currently we default to (1) instead of (5) when we detect that
the microcode detects both features. IBPB is not turned on by default
(you can see why below).

* Haswell and Skylake performance loss matrix using the following
test. This tests a high-concurrency compile, which is approximately
a 5:1 user:kernel test with high concurrency.

The haswell box is: i3-4130 CPU @ 3.40GHz (2-core/4-thread)
The skylake box is: i5-6500 CPU @ 3.20GHz (4-core/4-thread)

This does not include MMU isolation losses, which will add another
3-4% or so in losses.

(/usr/obj on tmpfs)
time make -j 8 nativekernel NO_MODULES=TRUE

PERFORMANCE LOSS MATRIX
HASWELL SKYLAKE
IBPB=0 IBPB=1 IBPB=0 IBPB=1
IBRS=0 0% 12% 0% 17%
IBRS=1 >12%< 21% >2.4%< 15%
IBRS=2 58% 60% 23% 32%

Note that the automatic default when microcode support is detected
is IBRS=1, IBPB=0 (12% loss on Haswell and 2.4% loss on Skylake
for this test). If we add 3-4% or so for MMU isolation, a Haswell
cpu loses around 16% and a Skylake cpu loses around 6% or so in
performance.

PERFORMANCE LOSS MATRIX
(including 3% MMU isolation losses)
HASWELL SKYLAKE
IBPB=0 IBPB=1 IBPB=0 IBPB=1
IBRS=0 3% 15% 3% 20%
IBRS=1 >15%< 24% >5.4%< 18%
IBRS=2 61% 63% 26% 35%

show more ...

kernel - Implement spectre mitigations part 1

* Implement machdep.spectre_mitigation. This can be set as a tunable
or sysctl'd later. The tunable is only applicable if the BIOS has
the appropr

kernel - Implement spectre mitigations part 1

* Implement machdep.spectre_mitigation. This can be set as a tunable
or sysctl'd later. The tunable is only applicable if the BIOS has
the appropriate microcode, otherwise you have to update the microcode
first and then use sysctl to set the mode.

This works similarly to Linux's IBRS support.

mode 0 - Spectre IBPB MSRs disabled

mode 1 - Sets IBPB MSR on USER->KERN transition and clear it
on KERN->USER.

mode 2 - Leave IBPB set globally. Do not toggle on USER->KERN or
KERN->USER transitions.

* Retest spectre microcode MSRs on microcode update.

* Spectre mode 1 is enabled by default if the microcode supports it.
(we might change this to disabled by default, I'm still mulling it
over).

* General performance effects (not counting the MMU separation mode,
which is machdep.meltdown_mitigation and adds another 3% in overhead):

Skylake loses around 5% for mode 1 and 12% for mode 2, verses mode 0.
Haswell loses around 12% for mode 1 and 53% for mode 2, verses mode 0.

Add another 3% if MMU separation is also turned on (aka
machdep.meltdown_mitigation).

* General system call overhead effects on Skylake:

machdep.meltdown_mitigation=0, machdep.spectre_mitigation=0 103ns
machdep.meltdown_mitigation=1, machdep.spectre_mitigation=0 360ns
machdep.meltdown_mitigation=1, machdep.spectre_mitigation=1 848ns
machdep.meltdown_mitigation=1, machdep.spectre_mitigation=2 404ns

Note that mode 1 has better overall performance for mixed user+kernel
workloads despite having a much higher system call overhead, whereas
mode 2 has lower system call overhead but generally lower overall
performance because IBPB is enabled in usermode.

show more ...

kernel - Intel user/kernel separation MMU bug fix part 1/3

* Part 1/3 of the fix for the Intel user/kernel separation MMU bug.
It appears that it is possible to discern the contents of kernel
me

kernel - Intel user/kernel separation MMU bug fix part 1/3

* Part 1/3 of the fix for the Intel user/kernel separation MMU bug.
It appears that it is possible to discern the contents of kernel
memory with careful timing measurements of instructions due to
speculative memory reads and speculative instruction execution
by Intel cpus. This can happen because Intel will allow both to
occur even when the memory access is later disallowed due to
privilege separation in the PTE.

Even though the execution is always aborted, the speculative
reads and speculative execution results in timing artifacts which
can be measured. A speculative compare/branch can lead to timing
artifacts that allow the actual contents of kernel memory to be
discerned.

While there are multiple speculative attacks possible, the Intel
bug is particularly bad because it allows a user program to more
or less effortlessly access kernel memory (and if a DMAP is
present, all of physical memory).

* Part 1 implements all the logic required to load an 'isolated'
version of the user process's PML4e into %cr3 on all user
transitions, and to load the 'normal' U+K version into %cr3 on
all transitions from user to kernel.

* Part 1 fully allocates, copies, and implements the %cr3 loads for
the 'isolated' version of the user process PML4e.

* Part 1 does not yet actually adjust the contents of this isolated
version to replace the kernel map with just a trampoline map in
kernel space. It does remove the DMAP as a test, though. The
full separation will be done in part 3.

show more ...

Remove advertising header from sys/

Correct BSD License clause numbering from 1-2-4 to 1-2-3.

Some less clear cases taken as it was done of FreeBSD.

kernel - Increase size of savefpu area in pcb for vkernel64

* The vkernel64 uses bcopy. The ucontext_t/mcontext_t reserves a 1024
byte space for the fpu area, but the savefpu structure only reser

kernel - Increase size of savefpu area in pcb for vkernel64

* The vkernel64 uses bcopy. The ucontext_t/mcontext_t reserves a 1024
byte space for the fpu area, but the savefpu structure only reserves
834 bytes. Increase the savefpu structure appropriately.

* Did not effect real 64-bit kernels because they used machine instructions
to save/restore the FP state and/or bcopy'd using the savefpu structure
sdize instead of the size of the fpu area in the ucontext/mcontext
structure.

* Fixes panics in vkernel64

Reported-by: tuxillo

show more ...

kernel - Make pcb_onfault more robust.

* Record the expected kernel stack pointer along with the pcb_onfault
action. Adjust the trap code to only take the action if the frame's
stack pointer ma

kernel - Make pcb_onfault more robust.

* Record the expected kernel stack pointer along with the pcb_onfault
action. Adjust the trap code to only take the action if the frame's
stack pointer matches the recorded expected stack pointer.

Otherwise this might be a recursive trap and we definitely do NOT want
to execute the on-fault stuff in that situation.

* Prior to these changes recursive traps during uiomove()s could result
in a kernel stack so corrupt that finding the actual cause of the panic
becomes impossible. This is believed to be making life difficult for us
trying to track down a particular i386 panic.

* On x86-64 we had to increase the size of the pcb structure. kgdb on
kernel cores and live kernels will be effected (needs recompile).

show more ...

Initial import of binutils 2.22 on the new vendor branch

Future versions of binutils will also reside on this branch rather
than continuing to create new binutils branches for each new version.

rename amd64 architecture to x86_64

The rest of the world seems to call amd64 x86_64. Bite the bullet and
rename all of the architecture files and references. This will
hopefully make pkgsrc build

rename amd64 architecture to x86_64

The rest of the world seems to call amd64 x86_64. Bite the bullet and
rename all of the architecture files and references. This will
hopefully make pkgsrc builds less painful.

Discussed-with: dillon@

show more ...

Revert "rename amd64 architecture to x86_64"

This reverts commit c1543a890188d397acca9fe7f76bcd982481a763.

I'm reverting it because:
1) the change didn't get properly discussed
2) it was based on

Revert "rename amd64 architecture to x86_64"

This reverts commit c1543a890188d397acca9fe7f76bcd982481a763.

I'm reverting it because:
1) the change didn't get properly discussed
2) it was based on false premises:
"The rest of the world seems to call amd64 x86_64."
3) no pkgsrc bulk build was done to test the change
4) the original committer acted irresponsibly by committing
such a big change just before going on vacation.

show more ...

rename amd64 architecture to x86_64

The rest of the world seems to call amd64 x86_64. Bite the bullet and
rename all of the architecture files and references. This will
hopefully make pkgsrc build

rename amd64 architecture to x86_64

The rest of the world seems to call amd64 x86_64. Bite the bullet and
rename all of the architecture files and references. This will
hopefully make pkgsrc builds less painful.

Discussed-with: dillon@

show more ...

amd64: Remove flag 'PCB_FULLCTX' now that it is unused.

AMD64 - Make signals operational, fix reg mappings, fix %fs management, trace

Adjust sigframe, trapframe, mcontext, ucontext, and regs. Add tf_xflags
too all structures. Reorder struct regs to mat

AMD64 - Make signals operational, fix reg mappings, fix %fs management, trace

Adjust sigframe, trapframe, mcontext, ucontext, and regs. Add tf_xflags
too all structures. Reorder struct regs to match the register layout
in the other structures.

Implement the commented out signaling code. Signals now work, or at least
do not crash programs. Theoretically the FP state is also saved and restored.

The exec() code failed to adjust gd_user_fs and gd_user_gs when setting
the msr registers for the user %fs and %gs, causing %fs to unexpectedly
change in running user programs.

Implement trace/debug support functions to set %rip and to single-step.

Define the missing vkernel flag FP_SOFTFP.

show more ...

AMD64 - Sync AMD64 support from Jordan Gordeev's svn repository and
Google SOC project. This work is still continuing but represents
substantial progress in the effort.

With this commit the world b

AMD64 - Sync AMD64 support from Jordan Gordeev's svn repository and
Google SOC project. This work is still continuing but represents
substantial progress in the effort.

With this commit the world builds and installs, the loader is able to
boot the kernel, and the kernel is able to initialize, probe devices, and
exec the init program. The init program is then able to run until it hits
its first fork(). For the purposes of the GSOC the project is being
considered a big success!

The code has been adapted from multiple sources, most notably Peter Wemm
and other peoples work from FreeBSD, with many modifications to make it
work with DragonFly. Also thanks go to Simon Schubert for working on gdb
and compiler issues, and to Noah Yan for a good chunk of precursor work
in 2007.

While Jordan wishes to be modest on his contribution, frankly we would
not have been able to make this much progress without the large number
of man-hours Jordan has dedicated to his GSOC project painstakingly gluing
code together, tracking down issues, and progressing the boot sequence.

Submitted-by: Jordan Gordeev <jgordeev@dir.bg>

show more ...

more header changes for amd64 port; the pc64 building infrastructure
and dummy sources as the initial skelecton.

Resurrect headers for sys/platform/pc64/include from CVS Attic.

Patch and mark them as platform specific.

On-behalf-of: Noah Yan <noah.yan@gmail.com>
Submitted-by: Noah Yan <noah.yan@gmail.com>