[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d5531acf-cd79-428d-80d1-eb7562cf3922@zytor.com>
Date: Wed, 12 Nov 2025 13:25:11 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Uros Bizjak <ubizjak@...il.com>
Cc: "Jason A. Donenfeld" <Jason@...c4.com>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
"Theodore Ts'o" <tytso@....edu>,
Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
Xin Li <xin@...or.com>, Andrew Cooper <andrew.cooper3@...rix.com>,
Andy Lutomirski <luto@...nel.org>, Ard Biesheuvel <ardb@...nel.org>,
Borislav Petkov <bp@...en8.de>, Brian Gerst <brgerst@...il.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>, James Morse <james.morse@....com>,
Jarkko Sakkinen <jarkko@...nel.org>,
Josh Poimboeuf <jpoimboe@...nel.org>, Kees Cook <kees@...nel.org>,
Nam Cao <namcao@...utronix.de>, Oleg Nesterov <oleg@...hat.com>,
Perry Yuan <perry.yuan@....com>, Thomas Gleixner <tglx@...utronix.de>,
Thomas Huth <thuth@...hat.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linux-sgx@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH v2 7/9] x86/vdso: abstract out vdso system call internals
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).
-hpa
Powered by blists - more mailing lists