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: <CAHk-=wivx7pi+h+hGmvNFAJm6StQLiQ-b8DdsE5J=LMOWae8Ng@mail.gmail.com>
Date: Fri, 6 Feb 2026 09:19:05 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Poimboeuf <jpoimboe@...nel.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, 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.

Longer term, we should probably clean this garbage up. The whole "use
inline functions with inline asm" for the vmware case makes zero sense
to begin with. Absolutely nobody cares. This is not
performance-critical code. We should get rid of those inlines in
<asm/vmware.h> *entirely*, and just make vmware_hypercall_slow() be
less of a shit-show.

Make that stupid switch statement in vmware_hypercall_slow() use a
static call, and get rid of the idiotic calling conventions that pass
in ten arguments, of which five are pointers that can be NULL. So
*OF*COURSE* the end result is a steaming pile of sh*t because the
calling convention is just a pile of dung that cannot be dealt with
well.

So make it do something like this instead:

        // Called 'in1,3-5' traditionally for bad reasons.
        // 'in2' was presumably apparently 'cmd' in cx
        // and ax is VMWARE_HYPERVISOR_MAGIC
        struct vmware_hypercall_args {
                unsigned long bx, dx, si, di;
        };

        // Called 'out1-5' traditionally for bad reasons.
        // 'in0' is returned in ax.
        struct vmware_hypercall_results {
                unsigned long bx, cx, dx, si, di;
        };

        unsigned long vmware_hypercall(unsigned long cmd,
                const struct vmware_hypercall_args *in,
                struct vmware_hypercall_results *out)
        {
                ... do sane code here ...

and I can almost guarantee it's going to be as fast or faster than the
existing crazy inline asm, because it won't have any stupid bad
calling conventions.

Then you can have trivial wrapper functions like

        static inline unsigned long vmware_hypercall1(unsigned long
cmd, unsigned long arg)
        {
                const struct vmware_hypercall_args in = { .bx = arg };
                struct vmware_hypercall_results out;
                return vmware_hypercall(cmd, &in, &out);
        }

and you're damn well done. Wouldn't that be a hell of a lot nicer -
and avoid the existing bug just by virtue of not having that stupid
and pointless "optimziation" where it thinks that si/di might be
useful around the vmware call.

The existing vmware code is just disgusting. Don't try to "fix it up"
for a bug that isn't even in the kernel.

Please.

                 Linus