kernel.git/arch/x86/kernel/msr.c, branch linux-5.19.y

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

x86/msr: Filter MSR writes

2020-06-25T08:39:02Z

Add functionality to disable writing to MSRs from userspace. Writes can still be allowed by supplying the allow_writes=on module parameter. The kernel will be tainted so that it shows in oopses. Having unfettered access to all MSRs on a system is and has always been a disaster waiting to happen. Think performance counter MSRs, MSRs with sticky or locked bits, MSRs making major system changes like loading microcode, MTRRs, PAT configuration, TSC counter, security mitigations MSRs, you name it. This also destroys all the kernel's caching of MSR values for performance, as the recent case with MSR_AMD64_LS_CFG showed. Another example is writing MSRs by mistake by simply typing the wrong MSR address. System freezes have been experienced that way. In general, poking at MSRs under the kernel's feet is a bad bad idea. So log writing to MSRs by default. Longer term, such writes will be disabled by default. If userspace still wants to do that, then proper interfaces should be defined which are under the kernel's control and accesses to those MSRs can be synchronized and sanitized properly. [ Fix sparse warnings. ] Reported-by: kernel test robot Signed-off-by: Borislav Petkov Tested-by: Sean Christopherson Link: https://lkml.kernel.org/r/20200612105026.GA22660@zn.tnic

x86/msr: Restrict MSR access when the kernel is locked down

2019-08-20T04:54:16Z

Writing to MSRs should not be allowed if the kernel is locked down, since it could lead to execution of arbitrary code in kernel mode. Based on a patch by Kees Cook. Signed-off-by: Matthew Garrett Signed-off-by: David Howells Acked-by: Kees Cook Reviewed-by: Thomas Gleixner cc: x86@kernel.org Signed-off-by: James Morris

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 142

2019-05-30T18:25:17Z

Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation inc 675 mass ave cambridge ma 02139 usa either version 2 of the license or at your option any later version incorporated herein by reference extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 4 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Richard Fontana Reviewed-by: Allison Randal Reviewed-by: Kate Stewart Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190524100844.465381181@linutronix.de Signed-off-by: Greg Kroah-Hartman

x86: Clean up 'sizeof x' => 'sizeof(x)'

2018-10-29T06:13:28Z

"sizeof(x)" is the canonical coding style used in arch/x86 most of the time. Fix the few places that didn't follow the convention. (Also do some whitespace cleanups in a few places while at it.) [ mingo: Rewrote the changelog. ] Signed-off-by: Jordan Borgner Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20181028125828.7rgammkgzep2wpam@JordanDesktop Signed-off-by: Ingo Molnar