aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/cpuctl
Commit message (Collapse)AuthorAgeFilesLines
* cpuctl: clean up empty lines in .c and .h filesMateusz Guzik2020-09-011-1/+0
| | | | Notes: svn path=/head/; revision=365220
* Control for Special Register Buffer Data Sampling mitigation.Konstantin Belousov2020-06-121-0/+1
| | | | | | | | | | | | | | | | | | | | New microcode update for Intel enables mitigation for SRBDS, which slows down RDSEED and related instructions. The update also provides a control to limit the mitigation to SGX enclaves, which should restore the speed of random generator by the cost of potential cross-core bufer sampling. See https://software.intel.com/security-software-guidance/insights/deep-dive-special-register-buffer-data-sampling GIve the user control over it. Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D25221 Notes: svn path=/head/; revision=362130
* Fix IBRS for machines with IBRS_ALL capability.Konstantin Belousov2020-02-251-1/+1
| | | | | | | | | | | | | | | | | 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 onr the CPU where sysctl was run. Properly report hw.ibrs_active for IBRS_ALL. Split hw_ibrs_ibpb_active out from ibrs_active, to keep the current semantic of guiding kernel entry and exit handlers. Reported and tested by: mav Sponsored by: The FreeBSD Foundation MFC after: 1 week Notes: svn path=/head/; revision=358315
* TSX Asynchronous Abort mitigation for Intel CVE-2019-11135.Scott Long2019-11-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CVE has already been announced in FreeBSD SA-19:26.mcu. Mitigation for TAA involves either turning off TSX or turning on the VERW mitigation used for MDS. Some CPUs will also be self-mitigating for 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 vulnerable Nothing in the base FreeBSD system uses TSX. However, the instructions are straight-forward to add to custom applications and require no kernel support, so the mitigation is provided for users with untrusted applications and tenants. Reviewed by: emaste, imp, kib, scottph Sponsored by: Intel Differential Revision: 22374 Notes: svn path=/head/; revision=354759
* Workaround for Intel SKL002/SKL012S errata.Konstantin Belousov2019-11-121-0/+5
| | | | | | | | | | | | | | | | | | | Disable the use of executable 2M page mappings in EPT-format page tables on affected CPUs. For bhyve virtual machines, this effectively disables all use of superpage mappings on affected CPUs. The vm.pmap.allow_2m_x_ept sysctl can be set to override the default and enable mappings on affected CPUs. Alternate approaches have been suggested, but at present we do not believe the complexity is warranted for typical bhyve's use cases. Reviewed by: alc, emaste, markj, scottl Security: CVE-2018-12207 Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D21884 Notes: svn path=/head/; revision=354649
* Mitigations for Microarchitectural Data Sampling.Konstantin Belousov2019-05-141-0/+1
| | | | | | | | | | | | | | | | | | Microarchitectural buffers on some Intel processors utilizing speculative execution may allow a local process to obtain a memory disclosure. An attacker may be able to read secret data from the kernel 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.html Security: CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091 Security: FreeBSD-SA-19:07.mds Reviewed by: jhb Tested by: emaste, lwhsu Approved by: so (gtetlow) Notes: svn path=/head/; revision=347566
* x86: Put other CPUs into tight loop when updating Intel microcode fromKonstantin Belousov2019-05-081-5/+21
| | | | | | | | | | | | | | | loaded OS. This should prevent at least some theoretical issues whith code execution on HT sibling of the core where the update is loaded. Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D20201 Notes: svn path=/head/; revision=347368
* amd64: flush L1 data cache on syscall return with an error.Konstantin Belousov2018-10-201-0/+3
| | | | | | | | | | | | | | | | | The knob allows to select the flushing mode or turn it off/on. The idea, as well as the list of the ignored syscall errors, were taken from https://www.openwall.com/lists/kernel-hardening/2018/10/11/10 . I was not able to measure statistically significant difference between flush enabled vs disabled using syscall_timing getuid. Reviewed by: bwidawsk Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D17536 Notes: svn path=/head/; revision=339507
* Log a message after a successful boot-time microcode update.Mark Johnston2018-09-141-1/+1
| | | | | | | | | | Reviewed by: kib Approved by: re (delphij) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17135 Notes: svn path=/head/; revision=338687
* Implement kernel support for early loading of Intel microcode updates.Mark Johnston2018-08-131-24/+13
| | | | | | | | | | | | | | | | | | | | | | | | Updates in the format described in section 9.11 of the Intel SDM can now be applied as one of the first steps in booting the kernel. Updates that are loaded this way are automatically re-applied upon exit from ACPI sleep states, in contrast with the existing cpucontrol(8)-based method. For the time being only Intel updates are supported. Microcode update files are passed to the kernel via loader(8). The file type must be "cpu_microcode" in order for the file to be recognized as a candidate microcode update. Updates for multiple CPU types may be concatenated together into a single file, in which case the kernel will select and apply a matching update. Memory used to store the update 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: kib MFC after: 6 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D16370 Notes: svn path=/head/; revision=337715
* Typo.Mark Johnston2018-05-221-1/+1
| | | | | | | | Reported by: rgrimes, vangyzen X-MFC with: r334050 Notes: svn path=/head/; revision=334051
* Flush caches before initiating a microcode update on Intel CPUs.Mark Johnston2018-05-221-1/+3
| | | | | | | | | | | | This apparently works around issues with updates of certain Broadwell CPUs. Reviewed by: emaste, kib, sbruno MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D15520 Notes: svn path=/head/; revision=334050
* Add Intel Spec Store Bypass Disable control.Konstantin Belousov2018-05-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Speculative Store Bypass (SSB) is a speculative execution side channel vulnerability identified by Jann Horn of Google Project Zero (GPZ) and Ken 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 a mitigation for the vulnerability. Introduce a sysctl hw.spec_store_bypass_disable to provide global control over the SSBD bit, akin to the existing sysctl that controls IBRS. The sysctl can be set to one of three values: 0: off 1: on 2: auto Future work will enable applications to control SSBD on a per-process basis (when it is not enabled globally). SSBD bit detection and control was verified with prerelease microcode. Security: CVE-2018-3639 Tested by: emaste (previous version, without updated microcode) Sponsored by: The FreeBSD Foundation MFC after: 3 days Notes: svn path=/head/; revision=334005
* IBRS support, AKA Spectre hardware mitigation.Konstantin Belousov2018-01-311-0/+1
| | | | | | | | | | | | | | | | | | | It is coded according to the Intel document 336996-001, reading of the patches posted on lkml, and some additional consultations with Intel. For existing processors, you need a microcode update which adds IBRS CPU features, and to manually enable it by setting the tunable/sysctl hw.ibrs_disable to 0. Current status can be checked in sysctl hw.ibrs_active. The mitigation might be inactive if the CPU feature is not patched in, or if CPU reports that IBRS use is not required, by IA32_ARCH_CAP_IBRS_ALL bit. Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D14029 Notes: svn path=/head/; revision=328625
* When re-evaluating cpu_features, also re-print CPU identification.Konstantin Belousov2018-01-141-0/+1
| | | | | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week Notes: svn path=/head/; revision=327963
* Make it possible to re-evaluate cpu_features.Konstantin Belousov2018-01-051-1/+29
| | | | | | | | | | | | | | | | | | | Add cpuctl(4) ioctl CPUCTL_EVAL_CPU_FEATURES which forces re-read of cpu_features, cpu_features2, cpu_stdext_features, and std_stdext_features2. The intent is to allow the kernel to see the changes in the CPU features after micocode update. Of course, the update is not atomic across variables and not synchronized with readers. See the man page warning as well. Reviewed by: imp (previous version), jilles Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D13770 Notes: svn path=/head/; revision=327597
* sys/dev: further adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-271-0/+2
| | | | | | | | | | | | | | | Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. Notes: svn path=/head/; revision=326255
* Update the list of cpudev ioctls which require write access.Konstantin Belousov2017-03-191-2/+3
| | | | | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week Notes: svn path=/head/; revision=315588
* Style.Konstantin Belousov2017-03-191-6/+9
| | | | | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week Notes: svn path=/head/; revision=315586
* Increase the max allowed size of the microcode update blob for x86.Konstantin Belousov2016-11-111-1/+1
| | | | | | | | | | | | | | | | | Newer CPUs (SkyLakes) have updates of 100K size, which is bigger than current limit 32K. Increase it to 4M but leave the check around to prevent kernel memory allocator abuse. Some time ago, the memory for update was allocated by contigmalloc(9), and it was reasonable to be conservative as much as possible. Since all uses of contigmalloc(9) appear to be either misunderstanding or too cautious, and were removed, provide more slack than strictly neccessary. Submitted by: Oliver Pinter MFC after: 1 week Differential revision: https://reviews.freebsd.org/D8486 Notes: svn path=/head/; revision=308538
* dev/cpuctl: put debug output under CPUCTL_DEBUG rather than DEBUGAndriy Gapon2016-11-021-1/+1
| | | | | | | | | | DEBUG is a well-known flag. It doesn't imply that there is a particular interest in cpuctl. MFC after: 1 week Notes: svn path=/head/; revision=308225
* Add support for microcode update on newer AMD CPUs (10h+)Andriy Gapon2016-11-021-29/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | This includes new code for parsing microcode files as well as the kernel-side change to apply the update on all processors at the same time. Developed with help from Borislav Petkov, formerly bp@amd64.org. Tested using Athlon II X2 processor on a system where BIOS does not 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-ucode Reviewed by: kib, stas MFC after: 2 weeks Relnotes: maybe Differential Revision: https://reviews.freebsd.org/D8384 Notes: svn path=/head/; revision=308218
* Replace a number of conflations of mp_ncpus and mp_maxid with eitherNathan Whitehorn2016-07-061-10/+10
| | | | | | | | | | | | | | | | | | | | | | mp_maxid or CPU_FOREACH() as appropriate. This fixes a number of places in the 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 too few buffers on systems with sparse CPU IDs in which there are holes in the range and mp_maxid > mp_ncpus. Such circumstances generally occur on systems with SMT, but on which SMT is disabled. This patch restores system operation at least on POWER8 systems configured in this way. There are a number of other places in the kernel with potential problems in these situations, but where sparse CPU IDs are not currently known to occur, mostly in the ARM machine-dependent code. These will be fixed in a follow-up commit after the stable/11 branch. PR: kern/210106 Reviewed by: jhb Approved by: re (glebius) Notes: svn path=/head/; revision=302372
* Always allow loading of cpuctl(4). When a CPU feature is notKonstantin Belousov2016-06-161-16/+22
| | | | | | | | | | | | supported, e.g. CPUID or MSR, return ENODEV from the ioctl which needs that feature. Sponsored by: The FreeBSD Foundation MFC after: 1 week Approved by: re (hrs) Notes: svn path=/head/; revision=301962
* Improve panic message by specifying on which cpu it really is.Andrey A. Chernov2016-05-221-1/+1
| | | | Notes: svn path=/head/; revision=300424
* Increase allowed size of the microcode blob to 32KB. Some Intel CPU'sKonstantin Belousov2014-12-201-1/+1
| | | | | | | | | | updates weight 28KB. PR: 179523 MFC after: 1 week Notes: svn path=/head/; revision=275960
* Make cpuctl_do_cpuid() and cpuctl_do_cpuid_count() return void.Konstantin Belousov2014-06-241-17/+11
| | | | | | | | | | | There is no error to report. Requested by: attilio Sponsored by: The FreeBSD Foundation MFC after: 1 week Notes: svn path=/head/; revision=267814
* Restore the ABI of the cpuctl(4) ioctl request CPUCTL_CPUID, useKonstantin Belousov2014-06-201-6/+12
| | | | | | | | | | | | separate argument structure with added level_type field for CPUID_CPUID_COUNT request. Reviewed by: attilio (previous version) Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Notes: svn path=/head/; revision=267673
* Following comments in r242565 add the possibility to specify ecx whenAttilio Rao2014-06-191-4/+19
| | | | | | | | | | | | | performing cpuid calls. Add also a new way to specify the level type to cpucontrol(8) as reported in the manpage. Sponsored by: EMC / Isilon storage division Reviewed by: bdrewery, gcooper Testerd by: bdrewery Notes: svn path=/head/; revision=267651
* Use correct types for sizeof() in the calculations for the malloc(9) sizes [1].Konstantin Belousov2014-03-121-7/+2
| | | | | | | | | | While there, remove unneeded checks for failed allocations with M_WAITOK flag. Submitted by: Conrad Meyer <cemeyer@uw.edu> [1] MFC after: 1 week Notes: svn path=/head/; revision=263080
* Call free() on the pointer returned from malloc().Konstantin Belousov2013-09-101-8/+8
| | | | | | | | | | Reported and tested by: Oliver Pinter <oliver.pntr@gmail.com> Sponsored by: The FreeBSD Foundation MFC after: 3 days Approved by: re (delphij) Notes: svn path=/head/; revision=255439
* Match malloc(9) calls with free(9), not contigfree(9). Also removeKonstantin Belousov2013-08-101-4/+2
| | | | | | | | | | | unneeded checks for NULL, free(9) can handle NULL pointers on its own, and the regions were allocated with M_WAITOK flag as well. Reported and tested by: Larry Rosenman <ler@lerctr.org> MFC after: 1 week Notes: svn path=/head/; revision=254191
* Increase the microcode max size to 16K to accomodate more recent IntelRui Paulo2013-07-031-1/+1
| | | | | | | firmware. Notes: svn path=/head/; revision=252597
* Typos in comments.Rui Paulo2013-07-031-3/+3
| | | | Notes: svn path=/head/; revision=252592
* cpuctl_do_cpuid: explicitly use ecx=0 for cpuid callAndriy Gapon2012-11-041-1/+1
| | | | | | | | | | | | ... instead of whatever random value may happen to be in the register. ecx is important to some cpuid leaves. To do: extend cpuctl interface to provide for ecx value parameter. MFC after: 5 days Notes: svn path=/head/; revision=242565
* Add VIA microde update support to cpuctl(4) and cpucontrol(8).Fabien Thomas2011-12-121-1/+80
| | | | | | | | | Support have been tested with X2 CPU and QuadCore CPU. MFC after: 1 month Notes: svn path=/head/; revision=228436
* - Add support to atomically set/clear individual bits of a MSR registerStanislav Sedov2009-06-301-2/+18
| | | | | | | | | | | | | | | | | | | | | | via cpuctl(4) driver. Two new CPUCTL_MSRSBIT and CPUCTL_MSRCBIT ioctl(2) calls treat the data field of the argument struct passed as a mask and set/clear bits of the MSR register according to the mask value. - Allow user to perform atomic bitwise AND and OR operaions on MSR registers via cpucontrol(8) utility. Two new operations ("&=" and "|=") have been added. The first one applies bitwise AND operaion between the current contents of the MSR register and the mask, and the second performs bitwise OR. The argument can be optionally prefixed with "~" inversion operator. This allows one to mimic the "clear bit" behavior by using the command like this: cpucontrol -m 0x10&=~0x02 # clear the second bit of TSC MSR Inversion operator support in all modes (assignment, OR, AND). Approved by: re (kib) MFC after: 1 month Notes: svn path=/head/; revision=195189
* - Don't zero data field in case of MSR write operation. Before this changeStanislav Sedov2009-06-261-4/+7
| | | | | | | | | | | | | | the value written to MSR register was always 0 regardless of value passed by user. - Use proper data pointer when performing AMD microcode update. Previously, the pointer to user-space data has been provided instead, which is totally incorrect. Approved by: re (kib) MFC after: 1 week Notes: svn path=/head/; revision=195081
* Replace all calls to minor() with dev2unit().Ed Schouten2008-09-271-2/+2
| | | | | | | | | | | | | | | | | | After I removed all the unit2minor()/minor2unit() calls from the kernel yesterday, I realised calling minor() everywhere is quite confusing. Character devices now only have the ability to store a unit number, not a minor number. Remove the confusion by using dev2unit() everywhere. This commit could also be considered as a bug fix. A lot of drivers call minor(), while they should actually be calling dev2unit(). In -CURRENT this isn't a problem, but it turns out we never had any problem reports related to that issue in the past. I suspect not many people connect more than 256 pieces of the same hardware. Reviewed by: kib Notes: svn path=/head/; revision=183397
* Remove unneeded D_NEEDMINOR from cpuctl(4).Ed Schouten2008-09-011-1/+0
| | | | | | | | | | | | | The D_NEEDMINOR flag was introduced for drivers that do not actually depend on storing a device unit/minor number, but require the ability to address the cdevs by this number, which is used by clone_create(). The cpuctl(4) driver sets D_NEEDMINOR, even though it doesn't use the clone_create() API. Remove the flag, because maybe we want to get rid of it somewhere in the far future. Notes: svn path=/head/; revision=182628
* - Add cpuctl(4) pseudo-device driver to provide access to some low-levelStanislav Sedov2008-08-081-0/+446
features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month Notes: svn path=/head/; revision=181430
generated by cgit v1.3 (git 2.53.0) at 2026-04-17 02:58:30 +0000