Re: [PATCH v2 7/9] x86/vdso: abstract out vdso system call internals

[Uros Bizjak]

On Wed, Nov 12, 2025 at 10:25 PM H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>
> On 2025-11-12 02:31, Uros Bizjak wrote:
> >
> > Unfortunately, %ebp is still special with -fno-omit-frame-pointer, so
> > using "ebp" as _sys_arg6 on 32-bit targets will result in:
> >
> > error: bp cannot be used in ‘asm’ here
> >
> > Please see how %ebp register is handled in
> > arch/x86/include/asm/vmware.h, vmware_hypercall_hb_out() and
> > vmware_hypercall_hb_in().
> >
>
> #ifdef CONFIG_X86_64
> #define VMW_BP_CONSTRAINT "r"
> #else
> #define VMW_BP_CONSTRAINT "m"
> #endif
>
>         asm_inline volatile (
>                 UNWIND_HINT_SAVE
>                 "push %%" _ASM_BP "\n\t"
>                 UNWIND_HINT_UNDEFINED
>                 "mov %[in6], %%" _ASM_BP "\n\t"
>                 "rep outsb\n\t"
>                 "pop %%" _ASM_BP "\n\t"
>                 UNWIND_HINT_RESTORE
>                 : "=a" (out0), "=b" (*out1)
>                 : "a" (VMWARE_HYPERVISOR_MAGIC),
>                   "b" (cmd),
>                   "c" (in2),
>                   "d" (in3 | VMWARE_HYPERVISOR_PORT_HB),
>                   "S" (in4),
>                   "D" (in5),
>                   [in6] VMW_BP_CONSTRAINT (in6)
>                 : "cc", "memory");
>         return out0;
>
> That code is actually incorrect, in at least two ways:
>
>
> 1. It should be conditioned on frame pointers enabled, not x86-64 vs i386.
> 2. The compiler is perfectly within its right to emit an %esp-relative
>    reference for the "m"-constrained [in6]. This is particularly likely
>    when *not* compiled with frame pointers, see #1.
>
> A better sequence might be:
>
>         pushl %[in6]
>         push %ebp
>         mov 4(%esp),%ebp
>         <stuff>
>         pop %ebp
>         pop %[junk]
>
> Then %[in6] can even safely be a "g" constraint (hence pushl).

If we want to also handle x86_64, the above code (including push)
needs to be 64-bit, with "rme" constraint for the pushed value.

I have CC'd the author of the above code, he might be interested in
the above discussion.

Uros.