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: <a78c4922-e355-4b85-a1aa-9aa3cc3dfca0@broadcom.com>
Date: Fri, 6 Feb 2026 14:41:51 -0800
From: Alexey Makhalov <alexey.makhalov@...adcom.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
 Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Thomas Gleixner <tglx@...-um.de>,
 Thorsten Leemhuis <regressions@...mhuis.info>, 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 2/6/26 9:19 AM, Linus Torvalds wrote:
> 
> 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.
> 
Thanks, Linus, for the suggestion.

vmware_hypercallX family of functions follows the idea of kvm_hypercallX 
from <asm/kvm_para.h>. But legacy and variations of possible 
combinations made it hairy.

Having just one wide hypercall implementation and multiple wrappers will 
definitely be more readable and maintainable. Questionable about 
performance though.

I'll work on it.
We will also analyze the possibility of the backdoor deprecation from 
the Linux kernel side.

--Alexey