linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "tip-bot2 for Borislav Petkov" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: kernel test robot <lkp@intel.com>, Borislav Petkov <bp@suse.de>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	x86 <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: [tip: x86/misc] x86/msr: Filter MSR writes
Date: Thu, 25 Jun 2020 08:45:38 -0000	[thread overview]
Message-ID: <159307473887.16989.17345471306220440079.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20200612105026.GA22660@zn.tnic>

The following commit has been merged into the x86/misc branch of tip:

Commit-ID:     a7e1f67ed29f0c339e2aa7483d13b085127566ab
Gitweb:        https://git.kernel.org/tip/a7e1f67ed29f0c339e2aa7483d13b085127566ab
Author:        Borislav Petkov <bp@suse.de>
AuthorDate:    Wed, 10 Jun 2020 21:37:49 +02:00
Committer:     Borislav Petkov <bp@suse.de>
CommitterDate: Thu, 25 Jun 2020 10:39:02 +02:00

x86/msr: Filter MSR writes

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 <lkp@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Sean Christopherson <sean.j.christopherson@intel.com>
Link: https://lkml.kernel.org/r/20200612105026.GA22660@zn.tnic
---
 arch/x86/kernel/msr.c | 69 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 69 insertions(+)

diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 1547be3..49dcfb8 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -42,6 +42,14 @@
 static struct class *msr_class;
 static enum cpuhp_state cpuhp_msr_state;
 
+enum allow_write_msrs {
+	MSR_WRITES_ON,
+	MSR_WRITES_OFF,
+	MSR_WRITES_DEFAULT,
+};
+
+static enum allow_write_msrs allow_writes = MSR_WRITES_DEFAULT;
+
 static ssize_t msr_read(struct file *file, char __user *buf,
 			size_t count, loff_t *ppos)
 {
@@ -70,6 +78,24 @@ static ssize_t msr_read(struct file *file, char __user *buf,
 	return bytes ? bytes : err;
 }
 
+static int filter_write(u32 reg)
+{
+	switch (allow_writes) {
+	case MSR_WRITES_ON:  return 0;
+	case MSR_WRITES_OFF: return -EPERM;
+	default: break;
+	}
+
+	if (reg == MSR_IA32_ENERGY_PERF_BIAS)
+		return 0;
+
+	pr_err_ratelimited("Write to unrecognized MSR 0x%x by %s\n"
+			   "Please report to x86@kernel.org\n",
+			   reg, current->comm);
+
+	return 0;
+}
+
 static ssize_t msr_write(struct file *file, const char __user *buf,
 			 size_t count, loff_t *ppos)
 {
@@ -84,6 +110,10 @@ static ssize_t msr_write(struct file *file, const char __user *buf,
 	if (err)
 		return err;
 
+	err = filter_write(reg);
+	if (err)
+		return err;
+
 	if (count % 8)
 		return -EINVAL;	/* Invalid chunk size */
 
@@ -92,9 +122,13 @@ static ssize_t msr_write(struct file *file, const char __user *buf,
 			err = -EFAULT;
 			break;
 		}
+
+		add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
+
 		err = wrmsr_safe_on_cpu(cpu, reg, data[0], data[1]);
 		if (err)
 			break;
+
 		tmp += 2;
 		bytes += 8;
 	}
@@ -242,6 +276,41 @@ static void __exit msr_exit(void)
 }
 module_exit(msr_exit)
 
+static int set_allow_writes(const char *val, const struct kernel_param *cp)
+{
+	/* val is NUL-terminated, see kernfs_fop_write() */
+	char *s = strstrip((char *)val);
+
+	if (!strcmp(s, "on"))
+		allow_writes = MSR_WRITES_ON;
+	else if (!strcmp(s, "off"))
+		allow_writes = MSR_WRITES_OFF;
+	else
+		allow_writes = MSR_WRITES_DEFAULT;
+
+	return 0;
+}
+
+static int get_allow_writes(char *buf, const struct kernel_param *kp)
+{
+	const char *res;
+
+	switch (allow_writes) {
+	case MSR_WRITES_ON:  res = "on"; break;
+	case MSR_WRITES_OFF: res = "off"; break;
+	default: res = "default"; break;
+	}
+
+	return sprintf(buf, "%s\n", res);
+}
+
+static const struct kernel_param_ops allow_writes_ops = {
+	.set = set_allow_writes,
+	.get = get_allow_writes
+};
+
+module_param_cb(allow_writes, &allow_writes_ops, NULL, 0600);
+
 MODULE_AUTHOR("H. Peter Anvin <hpa@zytor.com>");
 MODULE_DESCRIPTION("x86 generic MSR driver");
 MODULE_LICENSE("GPL");

      parent reply	other threads:[~2020-06-25  8:45 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-12 10:50 [RFC PATCH] x86/msr: Filter MSR writes Borislav Petkov
2020-06-12 16:34 ` Sean Christopherson
2020-06-12 16:46   ` Borislav Petkov
2020-06-12 16:57     ` Sean Christopherson
2020-06-12 17:03       ` Borislav Petkov
2020-06-12 17:43         ` Sean Christopherson
2020-06-12 17:52           ` Borislav Petkov
2020-06-12 17:20 ` Linus Torvalds
2020-06-12 17:48   ` Borislav Petkov
2020-06-12 19:47     ` Borislav Petkov
2020-06-12 20:39     ` Peter Zijlstra
2020-06-13  5:40       ` Tony Luck
2020-06-13  9:39       ` Borislav Petkov
2020-06-13 15:48 ` [PATCH -v2] " Borislav Petkov
2020-06-15  6:38   ` [PATCH -v2.1] " Borislav Petkov
2020-06-25  5:51     ` Sean Christopherson
2020-06-25  8:37       ` Borislav Petkov
2020-07-14 12:19     ` Chris Down
2020-07-14 15:47       ` Borislav Petkov
2020-07-14 16:04         ` Chris Down
2020-07-14 16:46           ` Luck, Tony
2020-07-14 16:58             ` Borislav Petkov
2020-07-14 17:02             ` Chris Down
2020-07-14 16:56           ` Borislav Petkov
2020-07-14 17:04             ` Chris Down
2020-07-14 18:52             ` Srinivas Pandruvada
2020-07-15  4:26               ` Borislav Petkov
2020-07-14 19:17           ` Matthew Garrett
2020-11-17 21:00             ` Mathieu Chouquet-Stringer
2020-11-17 21:20               ` Borislav Petkov
2020-11-18  8:58                 ` Mathieu Chouquet-Stringer
2020-11-18  9:09                 ` Mathieu Chouquet-Stringer
2020-11-18 11:50                   ` Borislav Petkov
2020-11-18 14:04                     ` [PATCH] " Mathieu Chouquet-Stringer
2020-11-18 17:50                       ` Borislav Petkov
2020-11-19 10:53                         ` Mathieu Chouquet-Stringer
2020-11-25 21:41                           ` Mathieu Chouquet-Stringer
2020-11-26 10:03                           ` Borislav Petkov
2020-11-17 21:21               ` [PATCH -v2.1] " Matthew Garrett
2020-11-17 21:22                 ` Matthew Garrett
2020-11-18  9:02                   ` Mathieu Chouquet-Stringer
2020-06-17 15:06 ` [tip: x86/misc] " tip-bot2 for Borislav Petkov
2020-06-25  8:45 ` tip-bot2 for Borislav Petkov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=159307473887.16989.17345471306220440079.tip-bot2@tip-bot2 \
    --to=tip-bot2@linutronix.de \
    --cc=bp@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).