[PATCH v1] x86/vmware: Fix i386 high-bandwidth hypercall arguments

[PATCH v1] x86/vmware: Fix i386 high-bandwidth hypercall arguments

[Zack Rusin]

The high-bandwidth hypercall helpers push %ebp before loading the in6
operand into it. On i386 without frame pointers, both GCC and Clang can
address the memory-constrained operand relative to %esp. The push then
moves the stack and the helpers load the wrong value.

Typical i386 configurations use the frame-pointer unwinder and happen to
address the operand through %ebp. However, UNWINDER_GUESS is available
with EXPERT and permits the affected frame-pointer-disabled configuration.
vmwgfx is also available on i386 and calls both helpers.

Stage in6 through %eax before changing either stack register, then save
%ebp and copy the staged value into it. Load the VMware magic immediately
before the string I/O instruction. Mark %eax early-clobber so it cannot
also provide in6 or an address register for it. Use the same sequence on
x86-64, where the full-width register preserves in6.

Fixes: 34bf25e820ae ("x86/vmware: Introduce VMware hypercall API")
Cc: stable@vger.kernel.org # 6.11+
Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
---

Notes:
    Built on v7.3-rc1 with W=1 on i386 using GCC and Clang, with frame
    pointers enabled and disabled. Disassembly in all four cases loads in6
    before changing %ebp or %esp.

 arch/x86/include/asm/vmware.h | 24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index 4220dae14a2d..fb011cef01e7 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -276,20 +276,22 @@ unsigned long vmware_hypercall_hb_out(unsigned long cmd, unsigned long in2,
 
 	asm_inline volatile (
 		UNWIND_HINT_SAVE
+		"mov %[in6], %%" _ASM_AX "\n\t"
 		"push %%" _ASM_BP "\n\t"
 		UNWIND_HINT_UNDEFINED
-		"mov %[in6], %%" _ASM_BP "\n\t"
+		"mov %%" _ASM_AX ", %%" _ASM_BP "\n\t"
+		"mov %[magic], %%eax\n\t"
 		"rep outsb\n\t"
 		"pop %%" _ASM_BP "\n\t"
 		UNWIND_HINT_RESTORE
-		: "=a" (out0), "=b" (*out1)
-		: "a" (VMWARE_HYPERVISOR_MAGIC),
-		  "b" (cmd),
+		: "=&a" (out0), "=b" (*out1)
+		: "b" (cmd),
 		  "c" (in2),
 		  "d" (in3 | VMWARE_HYPERVISOR_PORT_HB),
 		  "S" (in4),
 		  "D" (in5),
-		  [in6] VMW_BP_CONSTRAINT (in6)
+		  [in6] VMW_BP_CONSTRAINT(in6),
+		  [magic] "i" (VMWARE_HYPERVISOR_MAGIC)
 		: "cc", "memory");
 	return out0;
 }
@@ -304,20 +306,22 @@ unsigned long vmware_hypercall_hb_in(unsigned long cmd, unsigned long in2,
 
 	asm_inline volatile (
 		UNWIND_HINT_SAVE
+		"mov %[in6], %%" _ASM_AX "\n\t"
 		"push %%" _ASM_BP "\n\t"
 		UNWIND_HINT_UNDEFINED
-		"mov %[in6], %%" _ASM_BP "\n\t"
+		"mov %%" _ASM_AX ", %%" _ASM_BP "\n\t"
+		"mov %[magic], %%eax\n\t"
 		"rep insb\n\t"
 		"pop %%" _ASM_BP "\n\t"
 		UNWIND_HINT_RESTORE
-		: "=a" (out0), "=b" (*out1)
-		: "a" (VMWARE_HYPERVISOR_MAGIC),
-		  "b" (cmd),
+		: "=&a" (out0), "=b" (*out1)
+		: "b" (cmd),
 		  "c" (in2),
 		  "d" (in3 | VMWARE_HYPERVISOR_PORT_HB),
 		  "S" (in4),
 		  "D" (in5),
-		  [in6] VMW_BP_CONSTRAINT (in6)
+		  [in6] VMW_BP_CONSTRAINT(in6),
+		  [magic] "i" (VMWARE_HYPERVISOR_MAGIC)
 		: "cc", "memory");
 	return out0;
 }

base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
-- 
2.53.0

Re: [PATCH v1] x86/vmware: Fix i386 high-bandwidth hypercall arguments

[Maaz Mombasawala]

LGTM!

Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>

-- 
Maaz Mombasawala <maaz.mombasawala@broadcom.com>

Re: [PATCH v1] x86/vmware: Fix i386 high-bandwidth hypercall arguments

[Zack Rusin]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

On Thu, Sep 3, 2026 at 12:07 PM Zack Rusin <zack.rusin@broadcom.com> wrote:
>
> The high-bandwidth hypercall helpers push %ebp before loading the in6
> operand into it. On i386 without frame pointers, both GCC and Clang can
> address the memory-constrained operand relative to %esp. The push then
> moves the stack and the helpers load the wrong value.
>
> Typical i386 configurations use the frame-pointer unwinder and happen to
> address the operand through %ebp. However, UNWINDER_GUESS is available
> with EXPERT and permits the affected frame-pointer-disabled configuration.
> vmwgfx is also available on i386 and calls both helpers.
>
> Stage in6 through %eax before changing either stack register, then save
> %ebp and copy the staged value into it. Load the VMware magic immediately
> before the string I/O instruction. Mark %eax early-clobber so it cannot
> also provide in6 or an address register for it. Use the same sequence on
> x86-64, where the full-width register preserves in6.
>
> Fixes: 34bf25e820ae ("x86/vmware: Introduce VMware hypercall API")
> Cc: stable@vger.kernel.org # 6.11+
> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>

Hi, Boris.

Gentle ping on this one. It's a stable fix for the i386 high-bandwidth
hypercalls (vmwgfx uses them), Maaz reviewed it, and it still applies
cleanly to v7.3. The hypercall cleanup series I'm about to post moves
this assembly out of line and is based on it, so it would help to know
whether it's queued or needs changes.

z

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5414 bytes --]

Re: [PATCH v1] x86/vmware: Fix i386 high-bandwidth hypercall arguments

[Borislav Petkov]

On Tue, Oct 20, 2026 at 11:34:23PM -0400, Zack Rusin wrote:
> Gentle ping on this one. It's a stable fix for the i386 high-bandwidth
> hypercalls (vmwgfx uses them), Maaz reviewed it, and it still applies
> cleanly to v7.3. The hypercall cleanup series I'm about to post moves
> this assembly out of line and is based on it, so it would help to know
> whether it's queued or needs changes.

Sashiko complains about some pre-existing issues:

https://sashiko.dev/#/patchset/4ab10678a8f50053934b62b56af81f881c1d3798.1788414669.git.zack.rusin%40broadcom.com

Please address them: if valid, you should see about fixing them, if not,
explain why they don't need to be fixed.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v1] x86/vmware: Fix i386 high-bandwidth hypercall arguments

[Peter Zijlstra]

On Thu, Sep 03, 2026 at 12:07:20PM -0400, Zack Rusin wrote:
> The high-bandwidth hypercall helpers push %ebp before loading the in6
> operand into it. On i386 without frame pointers, both GCC and Clang can
> address the memory-constrained operand relative to %esp. The push then
> moves the stack and the helpers load the wrong value.
> 
> Typical i386 configurations use the frame-pointer unwinder and happen to
> address the operand through %ebp. However, UNWINDER_GUESS is available
> with EXPERT and permits the affected frame-pointer-disabled configuration.
> vmwgfx is also available on i386 and calls both helpers.
> 
> Stage in6 through %eax before changing either stack register, then save
> %ebp and copy the staged value into it. Load the VMware magic immediately
> before the string I/O instruction. Mark %eax early-clobber so it cannot
> also provide in6 or an address register for it. Use the same sequence on
> x86-64, where the full-width register preserves in6.
> 
> Fixes: 34bf25e820ae ("x86/vmware: Introduce VMware hypercall API")
> Cc: stable@vger.kernel.org # 6.11+
> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
> ---

So I despise all these hypercalls that muck about with the [BS]P
registers. The Intel function call convention is much older than any of
them and yet they chose to violate it.

This is both vmware and hyperv.

If if were just me I'd have nak'ed the lot. But alas.

At least ARM64 people are (afaik) holding up and telling hyperv its
their problem.

Re: [PATCH v1] x86/vmware: Fix i386 high-bandwidth hypercall arguments

[Zack Rusin]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

On Wed, Oct 28, 2026 at 2:01 AM Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Oct 20, 2026 at 11:34:23PM -0400, Zack Rusin wrote:
> > Gentle ping on this one. It's a stable fix for the i386 high-bandwidth
> > hypercalls (vmwgfx uses them), Maaz reviewed it, and it still applies
> > cleanly to v7.3. The hypercall cleanup series I'm about to post moves
> > this assembly out of line and is based on it, so it would help to know
> > whether it's queued or needs changes.
>
> Sashiko complains about some pre-existing issues:
>
> https://sashiko.dev/#/patchset/4ab10678a8f50053934b62b56af81f881c1d3798.1788414669.git.zack.rusin%40broadcom.com
>
> Please address them: if valid, you should see about fixing them, if not,
> explain why they don't need to be fixed.

I haven't seen this. I need to update my kernel setup to fetch those
muted Sashiko reports. Anyway, both are valid but they're preexisting
issues in vmwgfx. I was planning to rip out most of that code in
vmwgfx but I can provide fixes for these two. We could land them via
your tree if you need them as a prerequisite for landing the above,
I'll just make sure nothing touches that code via the drm tree while
the changes are staged in yours. Or I can send out the vmwgfx fixes to
dri-devel and land them in parallel via the regular drm tree. Let me
know what you prefer.

z

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5414 bytes --]

Re: [PATCH v1] x86/vmware: Fix i386 high-bandwidth hypercall arguments

[Zack Rusin]

[-- Attachment #1: Type: text/plain, Size: 2517 bytes --]

On Wed, Oct 28, 2026 at 4:27 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Thu, Sep 03, 2026 at 12:07:20PM -0400, Zack Rusin wrote:
> > The high-bandwidth hypercall helpers push %ebp before loading the in6
> > operand into it. On i386 without frame pointers, both GCC and Clang can
> > address the memory-constrained operand relative to %esp. The push then
> > moves the stack and the helpers load the wrong value.
> >
> > Typical i386 configurations use the frame-pointer unwinder and happen to
> > address the operand through %ebp. However, UNWINDER_GUESS is available
> > with EXPERT and permits the affected frame-pointer-disabled configuration.
> > vmwgfx is also available on i386 and calls both helpers.
> >
> > Stage in6 through %eax before changing either stack register, then save
> > %ebp and copy the staged value into it. Load the VMware magic immediately
> > before the string I/O instruction. Mark %eax early-clobber so it cannot
> > also provide in6 or an address register for it. Use the same sequence on
> > x86-64, where the full-width register preserves in6.
> >
> > Fixes: 34bf25e820ae ("x86/vmware: Introduce VMware hypercall API")
> > Cc: stable@vger.kernel.org # 6.11+
> > Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
> > ---
>
> So I despise all these hypercalls that muck about with the [BS]P
> registers. The Intel function call convention is much older than any of
> them and yet they chose to violate it.

Personally I reserve my "despise" for more important things in life,
like celery or subscription services but I understand the sentiment. I
don't think anyone's here writing love sonnets about this convention.
I ranted about this internally in an old man yelling at a sun type of
way because existing hosts and guests depend on this layout so
"fixing" it would imply adding a new convention and still having to
support and fix bugs in this one.

> This is both vmware and hyperv.
>
> If if were just me I'd have nak'ed the lot. But alas.
>
> At least ARM64 people are (afaik) holding up and telling hyperv its
> their problem.

Our arm64 conventions don't have this issue ([BS]P just goes through
x6 there) our x86 low-bandwidth helpers also don't have it. I have a
possible path to fixing this in the kernel (we can't do anything about
our hypervisor but you don't care about that) by completely removing
the high-bandwidth vmware hypercalls from the kernel but it's a large
project and wouldn't help stable.

z

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5414 bytes --]

Re: [PATCH v1] x86/vmware: Fix i386 high-bandwidth hypercall arguments

[Borislav Petkov]

On Wed, Oct 28, 2026 at 08:02:52AM -0400, Zack Rusin wrote:
> I haven't seen this. I need to update my kernel setup to fetch those
> muted Sashiko reports. Anyway, both are valid but they're preexisting
> issues in vmwgfx. I was planning to rip out most of that code in
> vmwgfx but I can provide fixes for these two. We could land them via
> your tree if you need them as a prerequisite for landing the above,
> I'll just make sure nothing touches that code via the drm tree while
> the changes are staged in yours. Or I can send out the vmwgfx fixes to
> dri-devel and land them in parallel via the regular drm tree. Let me
> know what you prefer.

Oh, I was actually only pointing them out and they're not really
a prerequisite.

I thought you guys should see this if you haven't and perhaps take a look at
fixing them or documenting them, as this is our main modus operandi right now,
in the age of AI-finds-bugs-in-code.

But ripping them out is the best fix anyway! :)

Thx.

-- 
Regards/Gruss,
    Boris.

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