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

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: <B00D1422-204D-4ACE-AE00-94ACEA7430F7@zytor.com>
Date: Thu, 13 Nov 2025 20:40:39 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Uros Bizjak <ubizjak@...il.com>,
        Alexey Makhalov <alexey.makhalov@...adcom.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 November 12, 2025 11:15:08 PM PST, Uros Bizjak <ubizjak@...il.com> wrote:
>On Wed, Nov 12, 2025 at 10:25 PM H. Peter Anvin <hpa@...or.com> 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.
>

For 64 bits, if you need frame pointer support *and* frob %rsp, using:

xchg %[arg],%%rbp
<stuff>
xchg %[arg],%%rbp

... is probably easiest, with %[arg] in a register.