kernel.git/arch/x86/kernel/msr.c, branch linux-rolling-stable

x86/msr: Add CPU_OUT_OF_SPEC taint name to "unrecognized" pr_warn(msg)

2025-11-05T12:14:42Z

While restricting access, a7e1f67ed29f ("x86/msr: Filter MSR writes") also added warning and started tainting the kernel. But the warning message never mentioned tainting. Moreover, this uses the "CPU_OUT_OF_SPEC" flag which is not clearly related to MSRs: that flag is overloaded by several, fairly different situations, including some much scarier ones. So, without an expert around (thank you Dave Hansen), it would have been practically impossible to root cause the tainting from just the log file at hand. So it would be prudent to explicitly mention in the logs when the tainting happens so that debugging crashes can be made easier. Fix this by simply appending the CPU_OUT_OF_SPEC flag to the warning message. This readability issue happened when staring at logs involving the Intel Memory Latency Checker (among many other things going on in that log). The MLC disables hardware prefetch. [ bp: Massage and extend commit message. ] Signed-off-by: Marc Herbert Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20251101-tainted-msr-v1-1-e00658ba04d4@linux.intel.com

x86/MSR: make msr_class a static const structure

2023-08-05T06:31:42Z

Now that the driver core allows for struct class to be in read-only memory, move the msr_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: x86@kernel.org Suggested-by: Greg Kroah-Hartman Signed-off-by: Ivan Orlov Link: https://lore.kernel.org/r/20230620144431.583290-5-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

driver core: class: remove module * from class_create()

2023-03-17T14:16:33Z

The module pointer in class_create() never actually did anything, and it shouldn't have been requred to be set as a parameter even if it did something. So just remove it and fix up all callers of the function in the kernel tree at the same time. Cc: "Rafael J. Wysocki" Acked-by: Benjamin Tissoires Link: https://lore.kernel.org/r/20230313181843.1207845-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

driver core: make struct class.devnode() take a const *

2022-11-24T16:12:27Z

The devnode() in struct class should not be modifying the device that is passed into it, so mark it as a const * and propagate the function signature changes out into all relevant subsystems that use this callback. Cc: Fenghua Yu Cc: Reinette Chatre Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: x86@kernel.org Cc: "H. Peter Anvin" Cc: FUJITA Tomonori Cc: Jens Axboe Cc: Justin Sanders Cc: Arnd Bergmann Cc: Sumit Semwal Cc: Benjamin Gaignard Cc: Liam Mark Cc: Laura Abbott Cc: Brian Starkey Cc: John Stultz Cc: "Christian König" Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Dennis Dalessandro Cc: Dmitry Torokhov Cc: Mauro Carvalho Chehab Cc: Sean Young Cc: Frank Haverkamp Cc: Jiri Slaby Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Alex Williamson Cc: Cornelia Huck Cc: Kees Cook Cc: Anton Vorontsov Cc: Colin Cross Cc: Tony Luck Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Hans Verkuil Cc: Christophe JAILLET Cc: Xie Yongji Cc: Gautam Dawar Cc: Dan Carpenter Cc: Eli Cohen Cc: Parav Pandit Cc: Maxime Coquelin Cc: alsa-devel@alsa-project.org Cc: dri-devel@lists.freedesktop.org Cc: kvm@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: linux-block@vger.kernel.org Cc: linux-input@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: linux-rdma@vger.kernel.org Cc: linux-scsi@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Link: https://lore.kernel.org/r/20221123122523.1332370-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

x86/MSR: Filter MSR writes through X86_IOC_WRMSR_REGS ioctl too

2021-01-27T18:06:47Z

Commit a7e1f67ed29f ("x86/msr: Filter MSR writes") introduced a module parameter to disable writing to the MSR device file and tainted the kernel upon writing. As MSR registers can be written by the X86_IOC_WRMSR_REGS ioctl too, the same filtering and tainting should be applied to the ioctl as well. [ bp: Massage commit message and space out statements. ] Fixes: a7e1f67ed29f ("x86/msr: Filter MSR writes") Signed-off-by: Misono Tomohiro Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20210127122456.13939-1-misono.tomohiro@jp.fujitsu.com

x86/msr: Add a pointer to an URL which contains further details

2020-12-08T09:17:08Z

After having collected the majority of reports about MSRs being written by userspace tools and what tools those are, and all newer reports mostly repeating, add an URL where detailed information is gathered and kept up-to-date. Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20201205002825.19107-1-bp@alien8.de

x86/msr: Downgrade unrecognized MSR message

2020-11-19T09:46:54Z

It is a warning and not an error so use pr_warn(). Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20201118123806.19672-1-bp@alien8.de

x86/msr: Do not allow writes to MSR_IA32_ENERGY_PERF_BIAS

2020-11-16T16:44:04Z

Now that all in-kernel-tree users are converted to using the sysfs file, remove the MSR from the "allowlist". Signed-off-by: Borislav Petkov Reviewed-by: Shuah Khan Link: https://lkml.kernel.org/r/20201029190259.3476-5-bp@alien8.de

x86/msr: Make source of unrecognised MSR writes unambiguous

2020-08-22T09:40:38Z

In many cases, task_struct.comm isn't enough to distinguish the offender, since for interpreted languages it's likely just going to be "python3" or whatever. Add the pid to make it unambiguous. [ bp: Make the printk string a single line for easier grepping. ] Signed-off-by: Chris Down Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/6f6fbd0ee6c99bc5e47910db700a6642159db01b.1598011595.git.chris@chrisdown.name

x86/msr: Prevent userspace MSR access from dominating the console

2020-08-22T09:27:40Z

Applications which manipulate MSRs from userspace often do so infrequently, and all at once. As such, the default printk ratelimit architecture supplied by pr_err_ratelimited() doesn't do enough to prevent kmsg becoming completely overwhelmed with their messages and pushing other salient information out of the circular buffer. In one case, I saw over 80% of kmsg being filled with these messages, and the default kmsg buffer being completely filled less than 5 minutes after boot(!). Make things much less aggressive, while still achieving the original goal of fiter_write(). Operators will still get warnings that MSRs are being manipulated from userspace, but they won't have other also potentially useful messages pushed out of the kmsg buffer. Of course, one can boot with `allow_writes=1` to avoid these messages at all, but that then has the downfall that one doesn't get _any_ notification at all about these problems in the first place, and so is much less likely to forget to fix it. One might rather it was less binary: it was still logged, just less often, so that application developers _do_ have the incentive to improve their current methods, without the kernel having to push other useful stuff out of the kmsg buffer. This one example isn't the point, of course: I'm sure there are plenty of other non-ideal-but-pragmatic cases where people are writing to MSRs from userspace right now, and it will take time for those people to find other solutions. Overall, keep the intent of the original patch, while mitigating its sometimes heavy effects on kmsg composition. [ bp: Massage a bit. ] Signed-off-by: Chris Down Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/563994ef132ce6cffd28fc659254ca37d032b5ef.1598011595.git.chris@chrisdown.name