linux-kernel - Re: [PATCH 06/20] x86/msr: Standardize on 'u32' MSR indices in <asm/msr.h>

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z_dnraUGp0Vbzk6k@gmail.com>
Date: Thu, 10 Apr 2025 08:39:41 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Xin Li <xin@...or.com>
Cc: "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	Juergen Gross <jgross@...e.com>,
	Dave Hansen <dave.hansen@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 06/20] x86/msr: Standardize on 'u32' MSR indices in
 <asm/msr.h>


* Xin Li <xin@...or.com> wrote:

> On 4/9/2025 8:29 PM, H. Peter Anvin wrote:
> > On April 9, 2025 8:18:12 PM PDT, Xin Li <xin@...or.com> wrote:
> > > A question NOT related to this patch set, the MSR write API prototype
> > > defined in struct pv_cpu_ops as:
> > >     void (*write_msr)(unsigned int msr, unsigned low, unsigned high);
> > > 
> > > Will it be better to add "const" to its arguments?  I.e.,
> > >     void (*write_msr)(const u32 msr, const u32 low, const u32 high);
> > > 
> > 
> > No, that makes no sense (it would have absolutely no effect.)
> > 
> 
> For the API definition, yes, it has no effect.
> 
> While it makes the API definition more explicit, and its implementations
> for native and Xen would be:
> 
> void {native,xen}_write_msr(const u32 msr, const u32 low, const u32 high)
> {
>     ....
> }
> 
> not worth it at all?

No:

 - Using 'const' for input parameter pointers makes sense because it's 
   easy to have a bug like this in a utility function:

	obj_ptr->val = foo;

   this has a side effect on the calling context, spreading the local 
   rot, so to speak, corrupting the object not owned by this function.

 - Using 'const' for non-pointer input parameters makes little sense, 
   because the worst a function can do is to corrupt it locally:

	val_high = foo;

   ... but this bug won't be able to spread via corrupting objects 
   through a pointer, any bug will be limited to that function.

So neither the kernel, nor any of the major libraries such as glibc 
will typically use const for non-pointer function parameters, outside 
of very specific exceptions that strengthen the rule.

Thanks,

	Ingo