cpuctl: clean up empty lines in .c and .h files
Control for Special Register Buffer Data Sampling mitigation.New microcode update for Intel enables mitigation for SRBDS, whichslows down RDSEED and related instructions. The update also provides
Control for Special Register Buffer Data Sampling mitigation.New microcode update for Intel enables mitigation for SRBDS, whichslows down RDSEED and related instructions. The update also providesa control to limit the mitigation to SGX enclaves, which shouldrestore the speed of random generator by the cost of potentialcross-core bufer sampling.See https://software.intel.com/security-software-guidance/insights/deep-dive-special-register-buffer-data-samplingGIve the user control over it.Reviewed by: markjSponsored by: The FreeBSD FoundationMFC after: 1 weekDifferential revision: https://reviews.freebsd.org/D25221
show more ...
Fix IBRS for machines with IBRS_ALL capability.When turning IBRS mitigation using sysctl, as opposed to loader tunable,send IPI to tweak MSR on all cores. Right now code only performed MSR write
Fix IBRS for machines with IBRS_ALL capability.When turning IBRS mitigation using sysctl, as opposed to loader tunable,send IPI to tweak MSR on all cores. Right now code only performed MSR writeonr the CPU where sysctl was run.Properly report hw.ibrs_active for IBRS_ALL. Split hw_ibrs_ibpb_active outfrom ibrs_active, to keep the current semantic of guiding kernel entry andexit handlers.Reported and tested by: mavSponsored by: The FreeBSD FoundationMFC after: 1 week
TSX Asynchronous Abort mitigation for Intel CVE-2019-11135.This CVE has already been announced in FreeBSD SA-19:26.mcu.Mitigation for TAA involves either turning off TSX or turning on theVERW mit
TSX Asynchronous Abort mitigation for Intel CVE-2019-11135.This CVE has already been announced in FreeBSD SA-19:26.mcu.Mitigation for TAA involves either turning off TSX or turning on theVERW mitigation used for MDS. Some CPUs will also be self-mitigatingfor TAA and require no software workaround.Control knobs are:machdep.mitigations.taa.enable: 0 - no software mitigation is enabled 1 - attempt to disable TSX 2 - use the VERW mitigation 3 - automatically select the mitigation based on processor features.machdep.mitigations.taa.state: inactive - no mitigation is active/enabled TSX disable - TSX is disabled in the bare metal CPU as well as - any virtualized CPUs VERW - VERW instruction clears CPU buffers not vulnerable - The CPU has identified itself as not being vulnerableNothing in the base FreeBSD system uses TSX. However, the instructionsare straight-forward to add to custom applications and require no kernelsupport, so the mitigation is provided for users with untrustedapplications and tenants.Reviewed by: emaste, imp, kib, scottphSponsored by: IntelDifferential Revision: 22374
Workaround for Intel SKL002/SKL012S errata.Disable the use of executable 2M page mappings in EPT-format pagetables on affected CPUs. For bhyve virtual machines, this effectivelydisables all use
Workaround for Intel SKL002/SKL012S errata.Disable the use of executable 2M page mappings in EPT-format pagetables on affected CPUs. For bhyve virtual machines, this effectivelydisables all use of superpage mappings on affected CPUs. Thevm.pmap.allow_2m_x_ept sysctl can be set to override the default andenable mappings on affected CPUs.Alternate approaches have been suggested, but at present we do notbelieve the complexity is warranted for typical bhyve's use cases.Reviewed by: alc, emaste, markj, scottlSecurity: CVE-2018-12207Sponsored by: The FreeBSD FoundationDifferential revision: https://reviews.freebsd.org/D21884
Mitigations for Microarchitectural Data Sampling.Microarchitectural buffers on some Intel processors utilizingspeculative execution may allow a local process to obtain a memorydisclosure. An att
Mitigations for Microarchitectural Data Sampling.Microarchitectural buffers on some Intel processors utilizingspeculative execution may allow a local process to obtain a memorydisclosure. An attacker may be able to read secret data from thekernel or from a process when executing untrusted code (for example,in a web browser).Reference: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.htmlSecurity: CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091Security: FreeBSD-SA-19:07.mdsReviewed by: jhbTested by: emaste, lwhsuApproved by: so (gtetlow)
x86: Put other CPUs into tight loop when updating Intel microcode fromloaded OS.This should prevent at least some theoretical issues whith codeexecution on HT sibling of the core where the update
x86: Put other CPUs into tight loop when updating Intel microcode fromloaded OS.This should prevent at least some theoretical issues whith codeexecution on HT sibling of the core where the update is loaded.Reviewed by: markjSponsored by: The FreeBSD FoundationMFC after: 1 weekDifferential revision: https://reviews.freebsd.org/D20201
amd64: flush L1 data cache on syscall return with an error.The knob allows to select the flushing mode or turn it off/on. Theidea, as well as the list of the ignored syscall errors, were takenfr
amd64: flush L1 data cache on syscall return with an error.The knob allows to select the flushing mode or turn it off/on. Theidea, as well as the list of the ignored syscall errors, were takenfrom https://www.openwall.com/lists/kernel-hardening/2018/10/11/10 .I was not able to measure statistically significant difference betweenflush enabled vs disabled using syscall_timing getuid.Reviewed by: bwidawskSponsored by: The FreeBSD FoundationMFC after: 1 weekDifferential revision: https://reviews.freebsd.org/D17536
Log a message after a successful boot-time microcode update.Reviewed by: kibApproved by: re (delphij)Sponsored by: The FreeBSD FoundationDifferential Revision: https://reviews.freebsd.org/D17135
Implement kernel support for early loading of Intel microcode updates.Updates in the format described in section 9.11 of the Intel SDM cannow be applied as one of the first steps in booting the ke
Implement kernel support for early loading of Intel microcode updates.Updates in the format described in section 9.11 of the Intel SDM cannow be applied as one of the first steps in booting the kernel. Updatesthat are loaded this way are automatically re-applied upon exit fromACPI sleep states, in contrast with the existing cpucontrol(8)-basedmethod. For the time being only Intel updates are supported.Microcode update files are passed to the kernel via loader(8). Thefile type must be "cpu_microcode" in order for the file to be recognizedas a candidate microcode update. Updates for multiple CPU types may beconcatenated together into a single file, in which case the kernelwill select and apply a matching update. Memory used to store theupdate file will be freed back to the system once the update is applied,so this approach will not consume more memory than required.Reviewed by: kibMFC after: 6 weeksSponsored by: The FreeBSD FoundationDifferential Revision: https://reviews.freebsd.org/D16370
Typo.Reported by: rgrimes, vangyzenX-MFC with: r334050
Flush caches before initiating a microcode update on Intel CPUs.This apparently works around issues with updates of certain BroadwellCPUs.Reviewed by: emaste, kib, sbrunoMFC after: 3 daysDiffe
Flush caches before initiating a microcode update on Intel CPUs.This apparently works around issues with updates of certain BroadwellCPUs.Reviewed by: emaste, kib, sbrunoMFC after: 3 daysDifferential Revision: https://reviews.freebsd.org/D15520
Add Intel Spec Store Bypass Disable control.Speculative Store Bypass (SSB) is a speculative execution side channelvulnerability identified by Jann Horn of Google Project Zero (GPZ) andKen Johnson
Add Intel Spec Store Bypass Disable control.Speculative Store Bypass (SSB) is a speculative execution side channelvulnerability identified by Jann Horn of Google Project Zero (GPZ) andKen Johnson of the Microsoft Security Response Center (MSRC)https://bugs.chromium.org/p/project-zero/issues/detail?id=1528.Updated Intel microcode introduces a MSR bit to disable SSB as amitigation for the vulnerability.Introduce a sysctl hw.spec_store_bypass_disable to provide globalcontrol over the SSBD bit, akin to the existing sysctl that controlsIBRS. The sysctl can be set to one of three values:0: off1: on2: autoFuture work will enable applications to control SSBD on a per-processbasis (when it is not enabled globally).SSBD bit detection and control was verified with prerelease microcode.Security: CVE-2018-3639Tested by: emaste (previous version, without updated microcode)Sponsored by: The FreeBSD FoundationMFC after: 3 days
IBRS support, AKA Spectre hardware mitigation.It is coded according to the Intel document 336996-001, reading of thepatches posted on lkml, and some additional consultations with Intel.For exist
IBRS support, AKA Spectre hardware mitigation.It is coded according to the Intel document 336996-001, reading of thepatches posted on lkml, and some additional consultations with Intel.For existing processors, you need a microcode update which adds IBRSCPU features, and to manually enable it by setting the tunable/sysctlhw.ibrs_disable to 0. Current status can be checked in sysctlhw.ibrs_active. The mitigation might be inactive if the CPU featureis not patched in, or if CPU reports that IBRS use is not required, byIA32_ARCH_CAP_IBRS_ALL bit.Sponsored by: The FreeBSD FoundationMFC after: 1 weekDifferential revision: https://reviews.freebsd.org/D14029
When re-evaluating cpu_features, also re-print CPU identification.Sponsored by: The FreeBSD FoundationMFC after: 1 week
Make it possible to re-evaluate cpu_features.Add cpuctl(4) ioctl CPUCTL_EVAL_CPU_FEATURES which forces re-read ofcpu_features, cpu_features2, cpu_stdext_features, andstd_stdext_features2.The in
Make it possible to re-evaluate cpu_features.Add cpuctl(4) ioctl CPUCTL_EVAL_CPU_FEATURES which forces re-read ofcpu_features, cpu_features2, cpu_stdext_features, andstd_stdext_features2.The intent is to allow the kernel to see the changes in the CPUfeatures after micocode update. Of course, the update is not atomicacross variables and not synchronized with readers. See the man pagewarning as well.Reviewed by: imp (previous version), jillesSponsored by: The FreeBSD FoundationMFC after: 1 weekDifferential revision: https://reviews.freebsd.org/D13770
sys/dev: further adoption of SPDX licensing ID tags.Mainly focus on files that use BSD 2-Clause license, however the tool Iwas using misidentified many licenses so this was mostly a manual - error
sys/dev: further adoption of SPDX licensing ID tags.Mainly focus on files that use BSD 2-Clause license, however the tool Iwas using misidentified many licenses so this was mostly a manual - errorprone - task.The Software Package Data Exchange (SPDX) group provides a specificationto make it easier for automated tools to detect and summarize well knownopensource licenses. We are gradually adopting the specification, notingthat the tags are considered only advisory and do not, in any way,superceed or replace the license texts.
Update the list of cpudev ioctls which require write access.Sponsored by: The FreeBSD FoundationMFC after: 1 week
Style.Sponsored by: The FreeBSD FoundationMFC after: 1 week
Increase the max allowed size of the microcode update blob for x86.Newer CPUs (SkyLakes) have updates of 100K size, which is bigger thancurrent limit 32K. Increase it to 4M but leave the check aro
Increase the max allowed size of the microcode update blob for x86.Newer CPUs (SkyLakes) have updates of 100K size, which is bigger thancurrent limit 32K. Increase it to 4M but leave the check around toprevent kernel memory allocator abuse. Some time ago, the memory forupdate was allocated by contigmalloc(9), and it was reasonable to beconservative as much as possible. Since all uses of contigmalloc(9)appear to be either misunderstanding or too cautious, and wereremoved, provide more slack than strictly neccessary.Submitted by: Oliver PinterMFC after: 1 weekDifferential revision: https://reviews.freebsd.org/D8486
dev/cpuctl: put debug output under CPUCTL_DEBUG rather than DEBUGDEBUG is a well-known flag.It doesn't imply that there is a particular interest in cpuctl.MFC after: 1 week
Add support for microcode update on newer AMD CPUs (10h+)This includes new code for parsing microcode files as well asthe kernel-side change to apply the update on all processorsat the same time.
Add support for microcode update on newer AMD CPUs (10h+)This includes new code for parsing microcode files as well asthe kernel-side change to apply the update on all processorsat the same time.Developed with help from Borislav Petkov, formerly [email protected].Tested using Athlon II X2 processor on a system where BIOS doesnot have the latest microcode version:/boot/firmware/microcode_amd.bin: updating cpu /dev/cpuctl0 to revision 0x10000c7... done.The microcode file is taken from here:https://web.archive.org/web/20160528230514/http://www.amd64.org/microcode.html(note that the original site seems to be down at the moment)It can also be found here:https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucodeReviewed by: kib, stasMFC after: 2 weeksRelnotes: maybeDifferential Revision: https://reviews.freebsd.org/D8384
Replace a number of conflations of mp_ncpus and mp_maxid with eithermp_maxid or CPU_FOREACH() as appropriate. This fixes a number of places inthe kernel that assumed CPU IDs are dense in [0, mp_ncp
Replace a number of conflations of mp_ncpus and mp_maxid with eithermp_maxid or CPU_FOREACH() as appropriate. This fixes a number of places inthe kernel that assumed CPU IDs are dense in [0, mp_ncpus) and would try,for example, to run tasks on CPUs that did not exist or to allocate toofew buffers on systems with sparse CPU IDs in which there are holes in therange and mp_maxid > mp_ncpus. Such circumstances generally occur onsystems with SMT, but on which SMT is disabled. This patch restores systemoperation at least on POWER8 systems configured in this way.There are a number of other places in the kernel with potential problemsin these situations, but where sparse CPU IDs are not currently knownto occur, mostly in the ARM machine-dependent code. These will be fixedin a follow-up commit after the stable/11 branch.PR: kern/210106Reviewed by: jhbApproved by: re (glebius)
Always allow loading of cpuctl(4). When a CPU feature is notsupported, e.g. CPUID or MSR, return ENODEV from the ioctl which needsthat feature.Sponsored by: The FreeBSD FoundationMFC after: 1 w
Always allow loading of cpuctl(4). When a CPU feature is notsupported, e.g. CPUID or MSR, return ENODEV from the ioctl which needsthat feature.Sponsored by: The FreeBSD FoundationMFC after: 1 weekApproved by: re (hrs)
Improve panic message by specifying on which cpu it really is.
12