kernel/linux.git/drivers/base/cpu.c, branch v6.19.11

tick/nohz: Expose housekeeping CPUs in sysfs

2025-11-26T14:20:51+00:00

Expose the current system-defined list of housekeeping CPUs in a new sysfs file: /sys/devices/system/cpu/housekeeping. This provides userspace performance tuning tools and resource managers with a canonical, reliable method to accurately identify the cores responsible for essential kernel maintenance workloads (RCU, timer callbacks, and unbound workqueues). Currently, tooling must manually calculate the housekeeping set by parsing complex kernel boot parameters (like isolcpus= and nohz_full=) and system topology, which is prone to error. This dedicated file simplifies the configuration of low-latency workloads. Signed-off-by: Aaron Tomlin Link: https://patch.msgid.link/20251011012853.7539-2-atomlin@atomlin.com Signed-off-by: Greg Kroah-Hartman

tick/nohz: avoid showing '(null)' if nohz_full= not set

2025-11-26T14:20:49+00:00

In the context of CONFIG_NO_HZ_FULL=y, tick_nohz_full_mask (of type cpumask_var_t) is initialised to 0. Memory is only allocated to the cpumask data structure, in tick_nohz_full_setup(), when Linux kernel boot-time parameter "nohz_full=" is correctly specified (see housekeeping_setup()). If "nohz_full=" is not set and an attempt is made to read /sys/devices/system/cpu/nohz_full, '(null)' can be displayed: ❯ cat /sys/devices/system/cpu/nohz_full (null) This patch changes the output to print a newline (or 0x0A) instead of '(null)', making it consistent with print_cpus_isolated() behaviour. Signed-off-by: Aaron Tomlin Link: https://patch.msgid.link/20251011011830.6670-3-atomlin@atomlin.com Signed-off-by: Greg Kroah-Hartman

sysfs/cpu: Use DEVICE_ATTR_RO for nohz_full attribute

2025-11-26T14:20:49+00:00

The /sys/devices/system/cpu/nohz_full file is a read-only attribute that reports the CPUs configured for tickless operation (CONFIG_NO_HZ_FULL=y). The current definition uses the generic DEVICE_ATTR macro, which unnecessarily requires specifying the file mode (0444) and a NULL store operation pointer. This patch converts the definition to use the dedicated DEVICE_ATTR_RO macro. This correctly expresses the read-only nature of the attribute, removes the redundant mode field, and simplifies the code. As a related cleanup, rename the show function from print_cpus_nohz_full() to the standard nohz_full_show() for consistency with common sysfs attribute naming conventions. Signed-off-by: Aaron Tomlin Link: https://patch.msgid.link/20251011011830.6670-2-atomlin@atomlin.com Signed-off-by: Greg Kroah-Hartman

Merge 6.17-rc6 into driver-core-next

2025-09-15T06:26:05+00:00

We need the driver core fixes in here to build on top of. Signed-off-by: Greg Kroah-Hartman

drivers: base: fix "publically"->"publicly"

2025-09-06T17:52:17+00:00

Trivial fix to spelling mistake in comment text. Signed-off-by: Xichao Zhao Link: https://lore.kernel.org/r/20250827114021.476668-1-zhao.xichao@vivo.com Signed-off-by: Greg Kroah-Hartman

x86/vmscape: Enable the mitigation

2025-08-14T17:37:33+00:00

Enable the previously added mitigation for VMscape. Add the cmdline vmscape={off|ibpb|force} and sysfs reporting. Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Borislav Petkov (AMD) Reviewed-by: Dave Hansen

x86/bugs: Add a Transient Scheduler Attacks mitigation

2025-06-17T15:17:02+00:00

Add the required features detection glue to bugs.c et all in order to support the TSA mitigation. Co-developed-by: Kim Phillips Signed-off-by: Kim Phillips Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Pawan Gupta

Merge commit 'its-for-linus-20250509-merge' into x86/core, to resolve conflicts

2025-05-13T08:47:10+00:00

Conflicts: Documentation/admin-guide/hw-vuln/index.rst arch/x86/include/asm/cpufeatures.h arch/x86/kernel/alternative.c arch/x86/kernel/cpu/bugs.c arch/x86/kernel/cpu/common.c drivers/base/cpu.c include/linux/cpu.h Signed-off-by: Ingo Molnar

x86/its: Enable Indirect Target Selection mitigation

2025-05-09T20:22:05+00:00

Indirect Target Selection (ITS) is a bug in some pre-ADL Intel CPUs with eIBRS. It affects prediction of indirect branch and RETs in the lower half of cacheline. Due to ITS such branches may get wrongly predicted to a target of (direct or indirect) branch that is located in the upper half of the cacheline. Scope of impact =============== Guest/host isolation -------------------- When eIBRS is used for guest/host isolation, the indirect branches in the VMM may still be predicted with targets corresponding to branches in the guest. Intra-mode ---------- cBPF or other native gadgets can be used for intra-mode training and disclosure using ITS. User/kernel isolation --------------------- When eIBRS is enabled user/kernel isolation is not impacted. Indirect Branch Prediction Barrier (IBPB) ----------------------------------------- After an IBPB, indirect branches may be predicted with targets corresponding to direct branches which were executed prior to IBPB. This is mitigated by a microcode update. Add cmdline parameter indirect_target_selection=off|on|force to control the mitigation to relocate the affected branches to an ITS-safe thunk i.e. located in the upper half of cacheline. Also add the sysfs reporting. When retpoline mitigation is deployed, ITS safe-thunks are not needed, because retpoline sequence is already ITS-safe. Similarly, when call depth tracking (CDT) mitigation is deployed (retbleed=stuff), ITS safe return thunk is not used, as CDT prevents RSB-underflow. To not overcomplicate things, ITS mitigation is not supported with spectre-v2 lfence;jmp mitigation. Moreover, it is less practical to deploy lfence;jmp mitigation on ITS affected parts anyways. Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Josh Poimboeuf Reviewed-by: Alexandre Chartre

x86/cpu: Help users notice when running old Intel microcode

2025-04-22T06:33:52+00:00

Old microcode is bad for users and for kernel developers. For users, it exposes them to known fixed security and/or functional issues. These obviously rarely result in instant dumpster fires in every environment. But it is as important to keep your microcode up to date as it is to keep your kernel up to date. Old microcode also makes kernels harder to debug. A developer looking at an oops need to consider kernel bugs, known CPU issues and unknown CPU issues as possible causes. If they know the microcode is up to date, they can mostly eliminate known CPU issues as the cause. Make it easier to tell if CPU microcode is out of date. Add a list of released microcode. If the loaded microcode is older than the release, tell users in a place that folks can find it: /sys/devices/system/cpu/vulnerabilities/old_microcode Tell kernel kernel developers about it with the existing taint flag: TAINT_CPU_OUT_OF_SPEC == Discussion == When a user reports a potential kernel issue, it is very common to ask them to reproduce the issue on mainline. Running mainline, they will (independently from the distro) acquire a more up-to-date microcode version list. If their microcode is old, they will get a warning about the taint and kernel developers can take that into consideration when debugging. Just like any other entry in "vulnerabilities/", users are free to make their own assessment of their exposure. == Microcode Revision Discussion == The microcode versions in the table were generated from the Intel microcode git repo: 8ac9378a8487 ("microcode-20241112 Release") which as of this writing lags behind the latest microcode-20250211. It can be argued that the versions that the kernel picks to call "old" should be a revision or two old. Which specific version is picked is less important to me than picking *a* version and enforcing it. This repository contains only microcode versions that Intel has deemed to be OS-loadable. It is quite possible that the BIOS has loaded a newer microcode than the latest in this repo. If this happens, the system is considered to have new microcode, not old. Specifically, the sysfs file and taint flag answer the question: Is the CPU running on the latest OS-loadable microcode, or something even later that the BIOS loaded? In other words, Intel never publishes an authoritative list of CPUs and latest microcode revisions. Until it does, this is the best that Linux can do. Also note that the "intel-ucode-defs.h" file is simple, ugly and has lots of magic numbers. That's on purpose and should allow a single file to be shared across lots of stable kernel regardless of if they have the new "VFM" infrastructure or not. It was generated with a dumb script. == FAQ == Q: Does this tell me if my system is secure or insecure? A: No. It only tells you if your microcode was old when the system booted. Q: Should the kernel warn if the microcode list itself is too old? A: No. New kernels will get new microcode lists, both mainline and stable. The only way to have an old list is to be running an old kernel in which case you have bigger problems. Q: Is this for security or functional issues? A: Both. Q: If a given microcode update only has functional problems but no security issues, will it be considered old? A: Yes. All microcode image versions within a microcode release are treated identically. Intel appears to make security updates without disclosing them in the release notes. Thus, all updates are considered to be security-relevant. Q: Who runs old microcode? A: Anybody with an old distro. This happens all the time inside of Intel where there are lots of weird systems in labs that might not be getting regular distro updates and might also be running rather exotic microcode images. Q: If I update my microcode after booting will it stop saying "Vulnerable"? A: No. Just like all the other vulnerabilies, you need to reboot before the kernel will reassess your vulnerability. Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Cc: "Ahmed S. Darwish" Cc: Andrew Cooper Cc: Andy Lutomirski Cc: Brian Gerst Cc: John Ogness Cc: Josh Poimboeuf Cc: Juergen Gross Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Link: https://lore.kernel.org/all/20250421195659.CF426C07%40davehans-spike.ostc.intel.com (cherry picked from commit 9127865b15eb0a1bd05ad7efe29489c44394bdc1)