kernel - Add per-process capability-based restrictions

* This new system allows userland to set capability restrictions which
turns off numerous kernel features and root accesses. These restricti

kernel - Add per-process capability-based restrictions

* This new system allows userland to set capability restrictions which
turns off numerous kernel features and root accesses. These restrictions
are inherited by sub-processes recursively. Once set, restrictions cannot
be removed.

Basic restrictions that mimic an unadorned jail can be enabled without
creating a jail, but generally speaking real security also requires
creating a chrooted filesystem topology, and a jail is still needed
to really segregate processes from each other. If you do so, however,
you can (for example) disable mount/umount and most global root-only
features.

* Add new system calls and a manual page for syscap_get(2) and syscap_set(2)

* Add sys/caps.h

* Add the "setcaps" userland utility and manual page.

* Remove priv.9 and the priv_check infrastructure, replacing it with
a newly designed caps infrastructure.

* The intention is to add path restriction lists and similar features to
improve jailess security in the near future, and to optimize the
priv_check code.

show more ...

x86_64/specialreg.h: Add several MSR defines for NVMM

* Add MSR_IA32_FLUSH_CMD define, together with one bit define.
* Add various bit defines for MSR_IA32_MISC_ENABLE.
* Add MSR_AMD_NB_CFG, MSR_AMD

x86_64/specialreg.h: Add several MSR defines for NVMM

* Add MSR_IA32_FLUSH_CMD define, together with one bit define.
* Add various bit defines for MSR_IA32_MISC_ENABLE.
* Add MSR_AMD_NB_CFG, MSR_AMD_PATCH_LEVEL, MSR_AMD_LS_CFG,
and MSR_AMD_IC_CFG defines.
* Rename MSR_K8_UCODE_UPDATE -> MSR_AMD_PATCH_LOADER, for naming
consistency.

Taken from NetBSD and referred to FreeBSD.

show more ...

cpuctl - Implement close() properly for /dev/cpuctl*

* The cpuctl device didn't implement close(). Properly implement
it so close() on cpuctl descriptors succeeds.

Reported-by: zrj

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 - 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 - Increase microcode size limit from 32KB to 4MB

* Increase the microcode size limit to 4MB. Newer microcodes exceed
the previous 32KB limit. e.g. the latest Skylake microcode is 97KB.

*

kernel - Increase microcode size limit from 32KB to 4MB

* Increase the microcode size limit to 4MB. Newer microcodes exceed
the previous 32KB limit. e.g. the latest Skylake microcode is 97KB.

* Fixes cpucontrol -u operations on newer cpus.

Taken-from: FreeBSD

show more ...

Remove <sys/ioccom.h> inclusion from a number of files.

<sys/ioccom.h> should only be included from header files that define
ioctls.

kernel - Incidental MPLOCK removal (non-performance)

* Remove the MPLOCK in a ton of places that don't need it or can be
trivially tokenized or locked.

* Mostly non-performance adjustments, thoug

kernel - Incidental MPLOCK removal (non-performance)

* Remove the MPLOCK in a ton of places that don't need it or can be
trivially tokenized or locked.

* Mostly non-performance adjustments, though the X server does use
scmouse or sysmouse.

show more ...

cpuctl(4): Require write rights for CPUCTL_MSRSBIT and CPUCTL_MSRCBIT.

* Both CPUCTL_MSRSBIT and CPUCTL_MSRCBIT write MSR registers, so they
should require write rights like CPUCTL_WRMSR.

cpuctl(4): Sync with FreeBSD

Intel Haswell ucode loading needs more work.

No previous functional change intended.

Taken-from: FreeBSD

Fix a number of typos in manual pages and user-visible messages.

Import cpuctl pseudo device from FreeBSD

The cpuctl pseudo device allows to perform cpu microcode updates.