linux-kernel - Re: [PATCH] x86/vmware: Fix hypercall clobbers

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: <2aoadlgueumiq6hf74baskvk5eomsil7jfsxg4vf4ofaggbecl@7seilp4ou5nl>
Date: Fri, 6 Feb 2026 11:08:53 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Thomas Gleixner <tglx@...-um.de>, 
	Thorsten Leemhuis <regressions@...mhuis.info>, Alexey Makhalov <alexey.makhalov@...adcom.com>, x86@...nel.org, 
	linux-kernel@...r.kernel.org, Ajay Kaher <ajay.kaher@...adcom.com>, 
	bcm-kernel-feedback-list@...adcom.com, Peter Zijlstra <peterz@...radead.org>, 
	Justin Forbes <jforbes@...oraproject.org>, Linux kernel regressions list <regressions@...ts.linux.dev>
Subject: Re: [PATCH] x86/vmware: Fix hypercall clobbers

On Fri, Feb 06, 2026 at 09:19:05AM -0800, Linus Torvalds wrote:
> ,
> 
> On Fri, 6 Feb 2026 at 08:32, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> >
> > So a spot fix would need to be something like so:
> 
> So from what I can tell, this was never a kernel bug to begin with,
> and the actual bug is in QEMU. And the kernel change that exposes this
> is old, and apparently the main issue is that it also then depends on
> bad luck with a compiler that generates particular code that then
> shows the QEMU bug.
> 
> So what I'd suggest we do is to do the *minimal* workaround for the
> specific case of the broken QEMU mouse emulation, and not make the
> already ugly vmware code even worse like your patch.
> 
> And the minimal workaround is apparently just the
> vmmouse_report_events() oneliner that Alexey Makhalov suggested.

So even if we want to use the strategy of only protecting against those
compiler optimizations which we've seen with our own eyes, that
one-liner still isn't enough...

Looking at the binary, in addition to that vmware_hypercall4.constprop.4
keeping RDI/RSI live across the hypercall, there's a
vmware_hypercall3.constprop.0 doing the exact same thing:

0000000000000130 <vmware_hypercall3.constprop.0>:
	...
	179:	ed                   	in     (%dx),%eax
	17a:	89 1f                	mov    %ebx,(%rdi)
	17c:	89 0e                	mov    %ecx,(%rsi)
	17e:	5b                   	pop    %rbx
	17f:	e9 00 00 00 00       	jmp    184 <vmware_hypercall3.constprop.0+0x54>	180: R_X86_64_PLT32	__x86_return_thunk-0x4

So that's a 2nd hypercall site we'd need to fix.

BTW, I suspect the non-inline + constprop madness is caused by the use
of CONFIG_DEBUG_SECTION_MISMATCH which adds
-fno-inline-functions-called-once.  I would love to get rid of that
config option, it creates a lot of grief for me personally.

Anyway, how about just adding RDI/RSI to the clobbers list for those two
hypercalls?  It shouldn't have much of an impact on other sites anyway,
it should be rare for the compiler to want to keep di/si live in
general.

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index c9cf43d5ef23..4220dae14a2d 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -140,7 +140,7 @@ unsigned long vmware_hypercall3(unsigned long cmd, unsigned long in1,
 		  "b" (in1),
 		  "c" (cmd),
 		  "d" (0)
-		: "cc", "memory");
+		: "di", "si", "cc", "memory");
 	return out0;
 }
 
@@ -165,7 +165,7 @@ unsigned long vmware_hypercall4(unsigned long cmd, unsigned long in1,
 		  "b" (in1),
 		  "c" (cmd),
 		  "d" (0)
-		: "cc", "memory");
+		: "di", "si", "cc", "memory");
 	return out0;
 }