linux-kernel - Re: [PATCH v11 2/2] Drivers: hv: Introduce mshv

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20251112093704.GC4067720@noisy.programming.kicks-ass.net>
Date: Wed, 12 Nov 2025 10:37:04 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Michael Kelley <mhklinux@...look.com>
Cc: Naman Jain <namjain@...ux.microsoft.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Sean Christopherson <seanjc@...gle.com>,
	"K . Y . Srinivasan" <kys@...rosoft.com>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"H . Peter Anvin" <hpa@...or.com>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>,
	Mukesh Rathor <mrathor@...ux.microsoft.com>,
	Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>,
	Nuno Das Neves <nunodasneves@...ux.microsoft.com>,
	Christoph Hellwig <hch@...radead.org>,
	Saurabh Sengar <ssengar@...ux.microsoft.com>,
	ALOK TIWARI <alok.a.tiwari@...cle.com>
Subject: Re: [PATCH v11 2/2] Drivers: hv: Introduce mshv_vtl driver

On Wed, Nov 12, 2025 at 04:12:08AM +0000, Michael Kelley wrote:

> > @@ -96,3 +97,10 @@ SYM_FUNC_START(__mshv_vtl_return_call)
> >  	pop %rbp
> >  	RET
> >  SYM_FUNC_END(__mshv_vtl_return_call)
> > +
> > +	.section	.discard.addressable,"aw"
> > +	.align 8
> > +	.type 	__UNIQUE_ID_addressable___SCK____mshv_vtl_return_hypercall_662.0, @object
> > +	.size 	__UNIQUE_ID_addressable___SCK____mshv_vtl_return_hypercall_662.0, 8
> > +__UNIQUE_ID_addressable___SCK____mshv_vtl_return_hypercall_662.0:
> > +	.quad	__SCK____mshv_vtl_return_hypercall
> 
> This is pretty yucky itself. 

Definitely doesn't win any prizes, for sure. 

> Why is it better than calling out to a C function?

It keeps all the code in one place is a strong argument.

> Is it because in spite of the annotations, there's no guarantee the C
> compiler won't generate some code that messes up a register value? Or is
> there some other reason?

There is that too, a frame pointer build would be in its right to add a
stack frame (although they typically won't in this case). And the C ABI
doesn't provide the guarantees your need, so calling out into C is very
much you get to keep the pieces.

> Does the magic "_662.0" have any significance?  Or is it just some
> uniqueness salt on the symbol name?

Like Paolo already said, that's just the crazy generated by our
__ADRESSABLE() macro, this name is mostly irrelevant, all we really need
is a reference to that __SCK____mshv_vtl_return_hypercall symbol so it
ends up in the symbol table. (And the final link will then complain if
the symbol doesn't end up being resolved)

Keeping the name somewhat in line with __ADDRESSABLE() has the advantage
that you can clearly see where it comes from, but yeah, we can strip of
the number if you like.