[PATCH] x86/msr: Restrict /dev/cpu/*/msr read and write to a single MSR per call

[PATCH] x86/msr: Restrict /dev/cpu/*/msr read and write to a single MSR per call

[Tim Wiederhake]

Reading or writing /dev/cpu/*/msr with a buffer larger than 8 bytes
reads or writes not successive MSRs, but the same one over and over.
While documented, this behavior is unintuitive and not helpful.

Remove the loops and process a single 8-byte MSR value per call.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
---
This is a resend of a patch originally submitted in May 2023 [1],
updated to also cover msr_write and rebased to v7.1.

[1] https://lkml.org/lkml/2023/5/23/1230

 arch/x86/kernel/msr.c | 48 +++++++++++++++----------------------------
 1 file changed, 16 insertions(+), 32 deletions(-)

diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 4469c784eaa0..528a8e9b2319 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -10,8 +10,7 @@
  * x86 MSR access device
  *
  * This device is accessed by lseek() to the appropriate register number
- * and then read/write in chunks of 8 bytes.  A larger size means multiple
- * reads or writes of the same register.
+ * and then read/write in chunks of 8 bytes.
  *
  * This driver uses /dev/cpu/%d/msr where %d is the minor number, and on
  * an SMP box will direct the access to CPU %d.
@@ -57,24 +56,17 @@ static ssize_t msr_read(struct file *file, char __user *buf,
 	u32 reg = *ppos;
 	int cpu = iminor(file_inode(file));
 	int err = 0;
-	ssize_t bytes = 0;
 
-	if (count % 8)
+	if (count < 8)
 		return -EINVAL;	/* Invalid chunk size */
 
-	for (; count; count -= 8) {
-		err = rdmsr_safe_on_cpu(cpu, reg, &data[0], &data[1]);
-		if (err)
-			break;
-		if (copy_to_user(tmp, &data, 8)) {
-			err = -EFAULT;
-			break;
-		}
-		tmp += 2;
-		bytes += 8;
-	}
+	err = rdmsr_safe_on_cpu(cpu, reg, &data[0], &data[1]);
+	if (err)
+		return err;
+	if (copy_to_user(tmp, &data, 8))
+		return -EFAULT;
 
-	return bytes ? bytes : err;
+	return 8;
 }
 
 static int filter_write(u32 reg)
@@ -113,7 +105,6 @@ static ssize_t msr_write(struct file *file, const char __user *buf,
 	u32 reg = *ppos;
 	int cpu = iminor(file_inode(file));
 	int err = 0;
-	ssize_t bytes = 0;
 
 	err = security_locked_down(LOCKDOWN_MSR);
 	if (err)
@@ -123,26 +114,19 @@ static ssize_t msr_write(struct file *file, const char __user *buf,
 	if (err)
 		return err;
 
-	if (count % 8)
+	if (count < 8)
 		return -EINVAL;	/* Invalid chunk size */
 
-	for (; count; count -= 8) {
-		if (copy_from_user(&data, tmp, 8)) {
-			err = -EFAULT;
-			break;
-		}
-
-		add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
+	if (copy_from_user(&data, tmp, 8))
+		return -EFAULT;
 
-		err = wrmsr_safe_on_cpu(cpu, reg, data[0], data[1]);
-		if (err)
-			break;
+	add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
 
-		tmp += 2;
-		bytes += 8;
-	}
+	err = wrmsr_safe_on_cpu(cpu, reg, data[0], data[1]);
+	if (err)
+		return err;
 
-	return bytes ? bytes : err;
+	return 8;
 }
 
 static long msr_ioctl(struct file *file, unsigned int ioc, unsigned long arg)
-- 
2.52.0

Re: [PATCH] x86/msr: Restrict /dev/cpu/*/msr read and write to a single MSR per call

[H. Peter Anvin]

On June 26, 2026 10:40:36 AM PDT, Tim Wiederhake <twiederh@redhat.com> wrote:
>Reading or writing /dev/cpu/*/msr with a buffer larger than 8 bytes
>reads or writes not successive MSRs, but the same one over and over.
>While documented, this behavior is unintuitive and not helpful.
>
>Remove the loops and process a single 8-byte MSR value per call.
>
>Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
>---
>This is a resend of a patch originally submitted in May 2023 [1],
>updated to also cover msr_write and rebased to v7.1.
>
>[1] https://lkml.org/lkml/2023/5/23/1230
>
> arch/x86/kernel/msr.c | 48 +++++++++++++++----------------------------
> 1 file changed, 16 insertions(+), 32 deletions(-)
>
>diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
>index 4469c784eaa0..528a8e9b2319 100644
>--- a/arch/x86/kernel/msr.c
>+++ b/arch/x86/kernel/msr.c
>@@ -10,8 +10,7 @@
>  * x86 MSR access device
>  *
>  * This device is accessed by lseek() to the appropriate register number
>- * and then read/write in chunks of 8 bytes.  A larger size means multiple
>- * reads or writes of the same register.
>+ * and then read/write in chunks of 8 bytes.
>  *
>  * This driver uses /dev/cpu/%d/msr where %d is the minor number, and on
>  * an SMP box will direct the access to CPU %d.
>@@ -57,24 +56,17 @@ static ssize_t msr_read(struct file *file, char __user *buf,
> 	u32 reg = *ppos;
> 	int cpu = iminor(file_inode(file));
> 	int err = 0;
>-	ssize_t bytes = 0;
> 
>-	if (count % 8)
>+	if (count < 8)
> 		return -EINVAL;	/* Invalid chunk size */
> 
>-	for (; count; count -= 8) {
>-		err = rdmsr_safe_on_cpu(cpu, reg, &data[0], &data[1]);
>-		if (err)
>-			break;
>-		if (copy_to_user(tmp, &data, 8)) {
>-			err = -EFAULT;
>-			break;
>-		}
>-		tmp += 2;
>-		bytes += 8;
>-	}
>+	err = rdmsr_safe_on_cpu(cpu, reg, &data[0], &data[1]);
>+	if (err)
>+		return err;
>+	if (copy_to_user(tmp, &data, 8))
>+		return -EFAULT;
> 
>-	return bytes ? bytes : err;
>+	return 8;
> }
> 
> static int filter_write(u32 reg)
>@@ -113,7 +105,6 @@ static ssize_t msr_write(struct file *file, const char __user *buf,
> 	u32 reg = *ppos;
> 	int cpu = iminor(file_inode(file));
> 	int err = 0;
>-	ssize_t bytes = 0;
> 
> 	err = security_locked_down(LOCKDOWN_MSR);
> 	if (err)
>@@ -123,26 +114,19 @@ static ssize_t msr_write(struct file *file, const char __user *buf,
> 	if (err)
> 		return err;
> 
>-	if (count % 8)
>+	if (count < 8)
> 		return -EINVAL;	/* Invalid chunk size */
> 
>-	for (; count; count -= 8) {
>-		if (copy_from_user(&data, tmp, 8)) {
>-			err = -EFAULT;
>-			break;
>-		}
>-
>-		add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
>+	if (copy_from_user(&data, tmp, 8))
>+		return -EFAULT;
> 
>-		err = wrmsr_safe_on_cpu(cpu, reg, data[0], data[1]);
>-		if (err)
>-			break;
>+	add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
> 
>-		tmp += 2;
>-		bytes += 8;
>-	}
>+	err = wrmsr_safe_on_cpu(cpu, reg, data[0], data[1]);
>+	if (err)
>+		return err;
> 
>-	return bytes ? bytes : err;
>+	return 8;
> }
> 
> static long msr_ioctl(struct file *file, unsigned int ioc, unsigned long arg)

As you say, it is documented and intentional. It isn't necessarily useful for MSRs that behave like registers, but an MSR with I/O-like characteristics (say, a virtual MSR that accepts logging information) it can be useful.

Re: [PATCH] x86/msr: Restrict /dev/cpu/*/msr read and write to a single MSR per call

[Borislav Petkov]

On Fri, Jun 26, 2026 at 10:49:31AM -0700, H. Peter Anvin wrote:
> As you say, it is documented and intentional. It isn't necessarily useful
> for MSRs that behave like registers, but an MSR with I/O-like
> characteristics (say, a virtual MSR that accepts logging information) it can
> be useful.

I wouldn't mind at all if we spelled that out somewhere so that it is clear.
I really like the logging-by-writing-at-a-magic-MSR aspect of it.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

[PATCH v2 1/2] x86/msr: Document I/O-like MSR semantics in /dev/cpu/*/msr driver

[Tim Wiederhake]

Explain why msr_write and msr_read do not advance the index.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
---
 arch/x86/kernel/msr.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 4469c784eaa0..cc719a6b2ba3 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -13,6 +13,9 @@
  * and then read/write in chunks of 8 bytes.  A larger size means multiple
  * reads or writes of the same register.
  *
+ * Writing the same register multiple times can be useful for MSRs with
+ * I/O-like semantics, e.g. a virtual MSR that accepts logging information.
+ *
  * This driver uses /dev/cpu/%d/msr where %d is the minor number, and on
  * an SMP box will direct the access to CPU %d.
  */
-- 
2.52.0

[PATCH v2 2/2] x86/msr: Restrict /dev/cpu/*/msr read to a single MSR per call

[Tim Wiederhake]

Reading /dev/cpu/*/msr with a buffer larger than 8 bytes reads not
successive MSRs, but the same one over and over.  While documented,
this behavior is unintuitive: A user space caller issuing a 16-byte
read might reasonably expect to receive two consecutive MSRs rather
than the same register twice.

Remove the loop and process a single 8-byte MSR value per call to
avoid this ambiguity.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
---
 arch/x86/kernel/msr.c | 21 +++++++--------------
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index cc719a6b2ba3..1ea7bd393072 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -60,24 +60,17 @@ static ssize_t msr_read(struct file *file, char __user *buf,
 	u32 reg = *ppos;
 	int cpu = iminor(file_inode(file));
 	int err = 0;
-	ssize_t bytes = 0;
 
-	if (count % 8)
+	if (count < 8)
 		return -EINVAL;	/* Invalid chunk size */
 
-	for (; count; count -= 8) {
-		err = rdmsr_safe_on_cpu(cpu, reg, &data[0], &data[1]);
-		if (err)
-			break;
-		if (copy_to_user(tmp, &data, 8)) {
-			err = -EFAULT;
-			break;
-		}
-		tmp += 2;
-		bytes += 8;
-	}
+	err = rdmsr_safe_on_cpu(cpu, reg, &data[0], &data[1]);
+	if (err)
+		return err;
+	if (copy_to_user(tmp, &data, 8))
+		return -EFAULT;
 
-	return bytes ? bytes : err;
+	return 8;
 }
 
 static int filter_write(u32 reg)
-- 
2.52.0

Re: [PATCH v2 1/2] x86/msr: Document I/O-like MSR semantics in /dev/cpu/*/msr driver

[Tim Wiederhake]

On Fri, 2026-06-26 at 22:23 +0200, Tim Wiederhake wrote:
> Explain why msr_write and msr_read do not advance the index.
> 
> Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
> ---
>  arch/x86/kernel/msr.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
> index 4469c784eaa0..cc719a6b2ba3 100644
> --- a/arch/x86/kernel/msr.c
> +++ b/arch/x86/kernel/msr.c
> @@ -13,6 +13,9 @@
>   * and then read/write in chunks of 8 bytes.  A larger size means
> multiple
>   * reads or writes of the same register.
>   *
> + * Writing the same register multiple times can be useful for MSRs
> with
> + * I/O-like semantics, e.g. a virtual MSR that accepts logging
> information.
> + *
>   * This driver uses /dev/cpu/%d/msr where %d is the minor number,
> and on
>   * an SMP box will direct the access to CPU %d.
>   */

I think I did something wrong with git send-email. The cover letter got
lost:

[PATCH v2 0/2] x86/msr: Clarify and restrict /dev/cpu/*/msr read
behavior

This is v2 of a patch originally sent in May 2023 [1] and resent
against v7.1 [2].

v1 removed the loops from both msr_read() and msr_write().  H. Peter
Anvin pointed out [3] that MSRs with I/O-like semantics (e.g. a virtual
MSR that accepts logging information) make the write loop useful.

This version splits the change in two:

  1/2 adds a comment explaining why the driver loops over the same
      register, so future readers don't have to rediscover the
rationale.
  2/2 removes only the read loop, where repeated access to the same
      register is less obviously useful.

[1] https://lkml.org/lkml/2023/5/23/1230
[2]
https://lore.kernel.org/lkml/20260626174037.1128563-1-twiederh@redhat.com/
[3]
https://lore.kernel.org/lkml/33F430D0-EFE6-471F-B4A1-D5D20E1F65AD@zytor.com/

Tim Wiederhake (2):
  x86/msr: Document I/O-like MSR semantics in /dev/cpu/*/msr driver
  x86/msr: Restrict /dev/cpu/*/msr read to a single MSR per call

 arch/x86/kernel/msr.c | 24 ++++++++++--------------
 1 file changed, 10 insertions(+), 14 deletions(-)

--
2.52.0

Re: [PATCH v2 1/2] x86/msr: Document I/O-like MSR semantics in /dev/cpu/*/msr driver

[H. Peter Anvin]

On 2026-06-26 13:33, Tim Wiederhake wrote:
> 
> This version splits the change in two:
> 
>   1/2 adds a comment explaining why the driver loops over the same
>       register, so future readers don't have to rediscover the
> rationale.
>   2/2 removes only the read loop, where repeated access to the same
>       register is less obviously useful.
> 
The same applies to the read loop, although the use case(s) are obviously
different.

Either way, you risk breaking working tools for no reason.

	-hpa

Re: [PATCH v2 1/2] x86/msr: Document I/O-like MSR semantics in /dev/cpu/*/msr driver

[Tim Wiederhake]

On Fri, 2026-06-26 at 14:42 -0700, H. Peter Anvin wrote:
> On 2026-06-26 13:33, Tim Wiederhake wrote:
> > 
> > This version splits the change in two:
> > 
> >   1/2 adds a comment explaining why the driver loops over the same
> >       register, so future readers don't have to rediscover the
> > rationale.
> >   2/2 removes only the read loop, where repeated access to the same
> >       register is less obviously useful.
> > 
> The same applies to the read loop, although the use case(s) are
> obviously
> different.
> 
> Either way, you risk breaking working tools for no reason.
> 
> 	-hpa
While looking into this I also noticed that /dev/cpu/*/msr is the only
register-addressed character device that doesn't advance ppos on read.
/dev/cpu/*/cpuid, /dev/port, and /dev/nvram do. That causes ftell() and
lseek(SEEK_CUR, 0) to disagree after an fread(). I don't know how
important that is though, and whether that is more of a glibc issue.

Can you please point me to a tool that uses the multiple-read behavior?
I want to mention that in the file comment, but turbostat, rdmsr,
cpupower, coreboot's inteltool, all read exactly 8 bytes.

Thanks for the review,
Tim

Re: [PATCH v2 1/2] x86/msr: Document I/O-like MSR semantics in /dev/cpu/*/msr driver

[H. Peter Anvin]

On June 29, 2026 8:14:12 AM PDT, Tim Wiederhake <twiederh@redhat.com> wrote:
>On Fri, 2026-06-26 at 14:42 -0700, H. Peter Anvin wrote:
>> On 2026-06-26 13:33, Tim Wiederhake wrote:
>> > 
>> > This version splits the change in two:
>> > 
>> >   1/2 adds a comment explaining why the driver loops over the same
>> >       register, so future readers don't have to rediscover the
>> > rationale.
>> >   2/2 removes only the read loop, where repeated access to the same
>> >       register is less obviously useful.
>> > 
>> The same applies to the read loop, although the use case(s) are
>> obviously
>> different.
>> 
>> Either way, you risk breaking working tools for no reason.
>> 
>> 	-hpa
>While looking into this I also noticed that /dev/cpu/*/msr is the only
>register-addressed character device that doesn't advance ppos on read.
>/dev/cpu/*/cpuid, /dev/port, and /dev/nvram do. That causes ftell() and
>lseek(SEEK_CUR, 0) to disagree after an fread(). I don't know how
>important that is though, and whether that is more of a glibc issue.
>
>Can you please point me to a tool that uses the multiple-read behavior?
>I want to mention that in the file comment, but turbostat, rdmsr,
>cpupower, coreboot's inteltool, all read exactly 8 bytes.
>
>Thanks for the review,
>Tim
>
>

/dev/ioport behave(d) that way as well, and was the model. 

However, you are barking up the wrong tree here: when you want to change a 25-year-old API for no technical reason — your only argument raised has been aestetics — then the burden of proof is on *you* that you won't break anything.

Re: [PATCH v2 1/2] x86/msr: Document I/O-like MSR semantics in /dev/cpu/*/msr driver

[Tim Wiederhake]

On Mon, 2026-06-29 at 08:23 -0700, H. Peter Anvin wrote:
> On June 29, 2026 8:14:12 AM PDT, Tim Wiederhake <twiederh@redhat.com>
> wrote:
> > On Fri, 2026-06-26 at 14:42 -0700, H. Peter Anvin wrote:
> > > On 2026-06-26 13:33, Tim Wiederhake wrote:
> > > > 
> > > > This version splits the change in two:
> > > > 
> > > >   1/2 adds a comment explaining why the driver loops over the
> > > > same
> > > >       register, so future readers don't have to rediscover the
> > > > rationale.
> > > >   2/2 removes only the read loop, where repeated access to the
> > > > same
> > > >       register is less obviously useful.
> > > > 
> > > The same applies to the read loop, although the use case(s) are
> > > obviously
> > > different.
> > > 
> > > Either way, you risk breaking working tools for no reason.
> > > 
> > > 	-hpa
> > While looking into this I also noticed that /dev/cpu/*/msr is the
> > only
> > register-addressed character device that doesn't advance ppos on
> > read.
> > /dev/cpu/*/cpuid, /dev/port, and /dev/nvram do. That causes ftell()
> > and
> > lseek(SEEK_CUR, 0) to disagree after an fread(). I don't know how
> > important that is though, and whether that is more of a glibc
> > issue.
> > 
> > Can you please point me to a tool that uses the multiple-read
> > behavior?
> > I want to mention that in the file comment, but turbostat, rdmsr,
> > cpupower, coreboot's inteltool, all read exactly 8 bytes.
> > 
> > Thanks for the review,
> > Tim
> > 
> > 
> 
> /dev/ioport behave(d) that way as well, and was the model. 
> 
> However, you are barking up the wrong tree here: when you want to
> change a 25-year-old API for no technical reason — your only argument
> raised has been aestetics — then the burden of proof is on *you* that
> you won't break anything.

I find that behavior unexpected and would have loved to make it less
surprising, but you're right that I can't guarantee nothing breaks.
I'll resend the comment patch as v3.

Thanks for the /dev/ioport pointer.

Regards,
Tim